ETSITS129 274V8.0.0 



(2009-01) 



Technical Specification 



Universal Mobile Telecommunications System (UMTS); 

LTE; 

General Packet Radio Service (GPRS); 

Evolved GPRS Tunnelling Protocol (eGTP) for EPS 

(3GPP TS 29.274 version 8.0.0 Release 8) 



33i^ 





3GPP TS 29.274 version 8.0.0 Release 8 1 ETSI TS 1 29 274 V8.0.0 (2009-01 ) 



Reference 



DTS/TSGC-0429274V800 
Keywords 



LTE, UMTS 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel. : +33 4 92 94 42 00 Fax: +33 4 93 65 47 1 6 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.orq 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.orq/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.orq/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2009. 
All rights reserved. 

DECT™, PLUGTESTS™, UMTS™, TIPHON™, the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered 

for the benefit of its Members. 
2QppTM |g g jracle Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 

LTE™ is a Trade Mark of ETSI currently being registered 

for the benefit of its Members and of the 3GPP Organizational Partners. 

GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association. 



ETSI 



3GPP TS 29.274 version 8.0.0 Release 8 2 ETSI TS 1 29 274 V8.0.0 (2009-01 ) 



Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp ). 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). 

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or 
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. 

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under 
http://webapp.etsi.org/kev/quervform.asp . 



ETSI 



3GPP TS 29.274 version 8.0.0 Release 8 3 ETSI TS 1 29 274 V8.0.0 (2009-01 ) 



Contents 



Intellectual Property Rights 2 

Foreword 2 

Foreword 7 

1 Scope 8 

2 References 8 

3 Definitions, symbols and abbreviations 9 

3.1 Definitions 9 

3.2 Symbols 9 

3.3 Abbreviations 10 

4 General 11 

4.1 GTPPath 11 

4.2 GTP Tunnel 11 

4.3 Protocol stack 11 

4.3.1 UDP header and port numbers 12 

4.3.1.1 Request Messages 12 

4.3.1.2 Response Messages 12 

4.3.1.3 Version Not Supported Indication 12 

4.3.2 IP header and IP addresses 12 

4.3.2.1 Request Messages 12 

4.3.2.2 Response Messages 13 

4.3.2.3 Version Not Supported Indication 13 

4.3.3 Layer 2 13 

4.3.4 Layer 1 13 

4.4 Transmission Order and Bit Definitions 13 

5 GTP Header for Control Plane 14 

5.1 General format 14 

5.2 Control Plane GTP Extension Header 14 

5.3 GTP-C header for Echo and Version Not Supported messages 14 

5.4 EPC specific GTP-C header 15 

5.5 Usage of the GTPv2-C Header 15 

6 GTP-C Message Types and Message Formats 17 

6.1 Message Format and Type values 17 

6.1.1 Presence requirements of Information Elements 19 

6.1.2 Comprehension requirements for Information Elements 19 

6.1.3 Grouped Information Elements 20 

6.1.4 Information Element instance 21 

6.4 Message Granularity 21 

7 GTP-C messages 22 

7.1 Path Management Messages 22 

7.1.1 Echo Request 22 

7.1.2 Echo Response 22 

7.1.3 Version Not Supported Indication 22 

7.2 Tunnel Management Messages 22 

7.2.1 Create Session Request 23 

7.2.2 Create Session Response 25 

7.2.3 Create Bearer Request 27 

7.2.4 Create Bearer Response 28 

7.2.5 Bearer Resource Command 29 

7.2.6 Bearer Resource Failure Indication 29 

7.2.7 Modify Bearer Request 30 

7.2.8 Modify Bearer Response 33 



£75/ 



3GPP TS 29.274 version 8.0.0 Release 8 4 ETSI TS 1 29 274 V8.0.0 (2009-01 ) 

7.2.9 Delete Session Request and Delete Bearer Request 35 

7.2.9.1 Delete Session Request 35 

7.2.9.2 Delete Bearer Request 36 

7.2.10 Delete Session Response and Delete Bearer Response 37 

7.2.10.1 Delete Session Response 37 

7.2.10.2 Delete Bearer Response 38 

7.2.11 Downlink Data Notification messages 40 

7.2.11.1 Downlink Data Notification 40 

7.2.11.2 Downlink Data Notification Acknowledgement 40 

7.2.11.3 Downlink Data Notification Failure Indication 40 

7.2.12 Update User Plane Request 41 

7.2.13 Update User Plane Response 41 

7.2.14 Modify Bearer Command and Failure Indication 42 

7.2.14.1 Modify Bearer Command 42 

7.2.14.2 Modify Bearer Failure Indication 43 

7.2.15 Update Bearer Request 44 

7.2.16 Update Bearer Response 45 

7.2.17 Delete Bearer Command and Failure Indication 46 

7.2.17.1 Delete Bearer Command 46 

7.2.17.2 Delete Bearer Failure Indication 46 

7.2.18 Create Indirect Data Forwarding Tunnel Request 47 

7.2.19 Create Indirect Data Forwarding Tunnel Response 48 

7.2.20 Update Bearer Complete 49 

7.3 Mobility Management Messages 50 

7.3.1 Forward Relocation Request 50 

7.3.2 Forward Relocation Response 51 

7.3.3 Forward Relocation Complete Notification 54 

7.3.4 Forward Relocation Complete Acknowledge 54 

7.3.5 Context Request 54 

7.3.6 Context Response 56 

7.3.7 Context Acknowledge 57 

7.3.8 Identification Request 58 

7.3.9 Identification Response 59 

7.3.10 Forward SRNS Context Notification 60 

7.3.11 Forward SRNS Context Acknowledge 61 

7.3.12 Detach Notification 61 

7.3.13 Detach Acknowledge 62 

7.3.14 Change Notification Request 62 

7.3.15 Change Notification Response 63 

7.3.16 Relocation Cancel Request 63 

7.3.17 Relocation Cancel Response 64 

7.4 CS Fallback related messages 64 

7.4.1 Suspend Notification 64 

7.4.2 Suspend Acknowledge 64 

7.4.3 Resume Notification 65 

7.4.4 Resume Acknowledge 65 

7.4.5 CS Paging Indication 65 

7.5 Non-3GPP access related messages 65 

7.5.1 Create Forwarding Tunnel Request 65 

7.5.2 Create Forwarding Tunnel Response 66 

7.6 Reliable Delivery of Signalling Messages 67 

7.7 Error Handling 68 

7.7.1 Protocol Errors 68 

7.7.2 Different GTP Versions 68 

7.7.3 GTP Message Too Short 68 

7.7.4 Unknown GTP Signalling Message 68 

7.7.5 Unexpected GTP Signalling Message 68 

7.7.6 Missing Mandatory or Conditional Information Elements 68 

7.7.7 Invalid Length 69 

7.7.8 Invalid Mandatory or Conditional Information Element 69 

7.7.9 Invalid Optional Information Element 69 

7.7.10 Unknown Information Element 69 



£75/ 



3GPP TS 29.274 version 8.0.0 Release 8 5 ETSI TS 1 29 274 V8.0.0 (2009-01 ) 

7.7.11 Out of Sequence Information Elements 70 

7.7.12 Unexpected Information Element 70 

7.7.13 Repeated Information Elements 70 

7.7.14 Incorrect Optional Information Elements 70 

7.8 Path Failure 70 

7.9 Restoration and Recovery 71 

7.9.x Delete PDN Connection Set Request 71 

7.9.Y Delete PDN Connection Set Response 71 

7.10 Fallback to GTPvl mechanism 71 

7.11 Fallback to GTPvO 71 

8 GTP-C Information Elements 72 

8.1 Information Element Types 72 

8.2 Information Element Format 74 

8.3 International Mobile Subscriber Identity (IMSI) 75 

8.4 Cause 75 

8.5 Recovery (Restart Counter) 77 

8.6 Access Point Name (APN) 77 

8.7 Aggregate Maximum Bit Rate (AMBR) 77 

8.8 EPS Bearer ID (FBI) 78 

8.9 IP Address 78 

8.10 Mobile Equipment Identity (MEI) 78 

8.11 MSISDN 79 

8.12 Indication 79 

8.13 Protocol Configuration Options (PCO) 80 

8.14 PDN Address Allocation (PAA) 81 

8.15 Bearer Quality of Service (Bearer QoS) 81 

8.16 Flow Quality of Service (How QoS) 82 

8.17 RAT Type 82 

8.18 Serving Network 83 

8.19 Tunnel Endpoint Identifier for Control Plane (TEID-C) 83 

8.19a Tunnel Endpoint Identifier for User Plane (TEID-U) 83 

8.19b Tunnel Endpoint Identifier for User Plane with FBI (TEID-U FBI) 83 

8.20 EPS Bearer Level Traffic Flow Template (Bearer TFT) 84 

8.21 Traffic Aggregate Description (TAD) 84 

8.22 User Location Info (ULI) 84 

8.22.1 CGI field 85 

8.22.2 SAI field 85 

8.22.3 RAI field 85 

8.22.4 TAI field 86 

8.22.5 ECGI field 86 

8.23 Fully Qualified TEID (F-TEID) 86 

8.24 TMSI 88 

8.25 Global CN-Id 88 

8.26 Legacy Quality of Service (QoS) 88 

8.27 S103 PDN Data Forwarding Info (S103PDF) 89 

8.28 Sl-U Data Forwarding (SlUDF) 89 

8.29 Delay Value 90 

8.30 Bearer ID List 90 

8.31 Bearer Context 91 

8.32 SlOl IP Address 91 

8.33 S102 IP Address 92 

8.34 Charging ID 92 

8.35 Charging Characteristics 92 

8.36 Trace Information 93 

8.37 Bearer Flags 93 

8.38 Paging Cause 93 

8.39 PDN Type 94 

8.40 Procedure Transaction ID (PTI) 94 

8.41 DRX Parameter 94 

8.42 UE Network Capability 95 

8.43 MM Context 95 



£75/ 



3GPP TS 29.274 version 8.0.0 Release 8 6 ETSI TS 1 29 274 V8.0.0 (2009-01 ) 

8.44 PDN Connection 99 

8.45 ORE Key 100 

8.46 PDU Numbers 100 

8.47 EPS Bearer Contexts Prioritization (Contexts Prioritization) 101 

8.48 LMA IP Address 101 

8.49 Packet TMSI (P-TMSI) 101 

8.50 P-TMSI Signature 101 

8.51 Hop Counter 102 

8.52 Authentication Quintuplet 102 

8.53 Authentication Quadruplet 102 

8.54 Complete Request Message 103 

8.55 GUTI 103 

8.56 Fully Qualified Container (F-Container) 104 

8.57 Fully Qualified Cause (F-Cause) 104 

8.58 Selected PLMN ID 104 

8.59 Target Identification 105 

8.60 NSAPI 105 

8.61 Packet Flow ID 105 

8.62 RAB Context 106 

8.63 Source RNC PDCP context info 106 

8.64 UDP Source Port Number 106 

8.65 APN Restriction 107 

8.66 Selection Mode 107 

8.67 Cell Identification 107 

8.68 Bearer Control Mode 108 

8.69 Change Reporting Action 109 

8.70 PDN Connection Set Identifier (CSID) 109 

8.71 Private Extension 109 

9 Security 110 

10 IP - The Networking Technology used by GTP 110 

10.1 IP Version 110 

10.2 IP Fragmentation 110 

Annex A (informative): Change History Ill 

History 112 



£75/ 



3GPP TS 29.274 version 8.0.0 Release 8 7 ETSI TS 1 29 274 V8.0.0 (2009-01 ) 



Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document specifies the stage 3 of the control plane of the GPRS Tunnelling Protocol, Version 2 for 
Evolved Packet System interfaces (GTPv2-C). 

In this document, unless otherwise specified the S5 interface refers always to "GTP-based S5" and S8 interface refers 
always to "GTP-based S8" interface. 

GTPv2-C shall be used across the following EPC signalling interfaces: S3, S4, S5, S8, SIO, Sll and S16. 

GTPv2-C based protocols shall also be used across Sv (3GPP TS 29.280 [15]) and SlOl (3GPP TS 29.276 [14]) 
interfaces. 
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Release as the present document. 
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transport". 
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interface specification ". 

[23] 3GPP TS 24.301: "Non- Access-Stratum (NAS) protocol for Evolved Packet". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. 

GTP-PDU: GTP Protocol Data Unit is either a GTP-C Message or a GTP-U Message. GTP-U Message may be either a 
signalling message across the user plane tunnel, or a G-PDU (see clause 6). 

• Signalling Message: any GTP-PDU (GTP-C or GTP-U) except the G-PDU. 

• G-PDU: GTP user plane message, which carries the original packet (payload). G-PDU consists of GTP-U 
header and a T-PDU. 

• T-PDU: original packet, for example an IP datagram, from an UE or a network node in an external packet data 
network. A T-PDU is the payload that is tunnelled in the GTP-U tunnel. 

• GTP-C Message: GTP control plane message type of a GTP-PDU. GTP-C message consists of GTP-C 
header, which is followed by zero or more information elements. 

• GTP-U Message: GTP user plane message. The user plane messages are used to carry user data packets, and 
also signalling messages e.g. for path management and error indication. Therefore, GTP-U message consists of 
GTP-U header, which is followed by either a T-PDU, or zero or more information elements. 

GTP Tunnel: FFS (see also subclause 4.2 "GTP Tunnel"). 

Path: A pair of UDP/IP endpoints identify GTP path (see subclause 4. 1 "GTP Path"). 

Tunnel Endpoint: A tunnel endpoint is identified with a TEID, an IP address and a UDP port number (see subclause 
4.2 "GTP Tunnel"). 

Tunnel Endpoint Identifier (TEID): unambiguously identifies a tunnel endpoint in scope of a path (see subclause 4.2 
"GTP Tunnel"). 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

S 1-U Interface between SGW and eNB 

X2 Interface between eNBs 
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3.3 Abbreviations 

For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 

AMBR Aggregate Maximum Bit Rate 

APN Access Point Name 

APN-Nl Access Point Name Network Identifier 

APN-01 Access Point Name Operator Identifier 

CR Comprehension Required 

EBI EPS Bearer ID 

eBN Evolved Node B 

EPC Evolved Packet Core 

EPS Evolved Packet System 

F-TEID Fully Qualified Tunnel Endpoint Identifier 

G-PDU GTP-U non-signalling PDU 

GPRS General Packet Radio Service 

GTP GPRS Tunnelling Protocol 

GTP-PDU GTP-C PDU or GTP-U PDU 

GTPv2-C GTP version 2, control plane 

GTPv2-U GTP version 2, user plane 

IMSI International Mobile Subscriber Identity 

IP Internet Protocol 

LBI Linked Bearer identity 

LI Layer 1 

L2 Layer 2 

MEl Mobile Equipment Identity 

MSISDN Mobile Subscriber ISDN Number 

PAA PDN Address Allocation 

PCO Protocol Configuration Options 

PDU Protocol Data Unit 

PDN Packet Data Network or Public Data Network 

PGW PDN Gateway 

PTI Procedure Transaction Id 

QoS Quality of Service 

RAT Radio Access Type 

SGW Serving Gateway 

TEID Tunnel Endpoint Identifier 

TEID-C Tunnel Endpoint Identifier, control plane 

TEID-U Tunnel Endpoint Identifier, user plane 

TFT Traffic Flow Template 

TLIV Type Length Instance Value 

UDP User Datagram Protocol 

ULI User Location Info 
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4 General 

4.1 GTP Path 

A path is identified in each node with an IP address and a UDP port number. A path may be used to muhiplex GTP 
tunnels. 

4.2 GTP Tunnel 

GTP tunnels are used between two nodes communicating over a GTP based interface, to separate traffic into different 
communication flows. 

A GTP tunnel is identified in each node with a TEID, an IP address and a UDP port number. The receiving end side of a 
GTP tunnel locally assigns the TEID value the transmitting side has to use. The TEID values are exchanged between 
tunnel endpoints using GTP-C or Sl-MME messages. 

The criteria defining when the same or different GTP tunnels shall be used between to nodes differs between the control 
and the user plane, and also between interfaces. 

For the control plane, for each end-point of a GTP-C tunnel: 

The TEID-C is unique per PDN-Connection on GTP based S5 and S8. The same tunnel is shared for the control 
messages related to all bearers associated to the PDN-Connection. A TEID-C on S5/S8 interface is released 
after all its associated EPS bearers are deleted. 

There is only one pair of TEID-Cs per UE on each of the S3 and the S 10 interfaces. The same tunnel is shared 
for the control messages related to the same UE operation. A TEID-C on S3/S10 interface is released after its 
associated UE context is removed or the UE is detached. 

There is only one pair of TEID-C per UE over the S 11 and the S4 interface. The same tunnel is shared for the 
control messages related to the same UE operation. A TEID-C on S11/S4 interface is released after all its 
associated EPS bearers are deleted. 

For GTP-U, a TEID-U is used according to 3GPP TS 29.281 [13]. 

NOTE: GTP-U is based on GTP version 1 (GTPvl). 

4.3 Protocol stack 

Protocol stack for GTPv2 is depicted in Figure 4.3-1. 
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Figure 4.3-1 : GTPv2 stack 

GTPv2 headers are specified in respective clauses of this specification. 

4.3.1 UDP header and port numbers 

A User Datagram Protocol (UDP) compliant with IETF RFC 768 [7] shall be used. 



4.3.1.1 



Request Messages 



The UDP Destination Port number for GTP-C request messages is 2123. It is the registered port number for GTP-C. 
The UDP Source Port is a locally allocated port number at the sending GTP entity. 



4.3.1.2 



Response Messages 



The UDP Destination Port value shall be the value of the UDP Source Port of the corresponding request message. 
The UDP Source Port shall be the value from the UDP Destination Port of the corresponding request message. 

4.3.1 .3 Version Not Supported Indication 

The UDP Destination Port number for the Version Not Supported Indication shall be the UDP source port of the GTP 
packet that triggered the GTPv2 entity to send this message. 

The UDP Source Port number for the Version Not Supported Indication shall be the UDP destination port of the GTP 
packet that triggered the GTPv2 entity to send this message. 

4.3.2 IP header and IP addresses 
4.3.2.1 Request Messages 

The IP Source Address shall be an IP address of the source GTPv2 entity from which the message is originating. 
The IP Destination Address in a GTP request message shall be an IP address of the destination GTPv2 entity. 
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4.3.2.2 Response Messages 

The IP Source Address shall be copied from the IP destination address of the GTP request message to which this 
GTPv2 entity is replying. 

The IP Destination Address shall be copied from the IP Source Address of the GTP request message to which this 
GTPv2 entity is replying. 

4.3.2.3 Version Not Supported Indication 

The IP Source Address for the Version Not Supported Indication shall be set to the IP destination address of the GTP 
message that triggered the GTPv2 entity to send this message. 

The IP Destination Address for the Version Not Supported Indication shall be set to the IP source address of the GTP 
message that triggered the GTPv2 entity to send this message. 

4.3.3 Layer 2 

Typically Ethernet will be used as a Layer 2 protocol, but operators may use any other technology. 

4.3.4 Layer 1 

Operators may use any Layer 1 technology. 

4.4 Transmission Order and Bit Definitions 

The messages in this document shall be transmitted in network octet order starting with octet 1 . 

The most significant bit of an octet in a GTP message is bit 8. If a value in a GTP message spans several octets and 
nothing else is stated, the most significant bit is bit 8 of the octet with the lowest number. 
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GTP Header for Control Plane 



5.1 



General format 



Control Plane GTP uses a variable length header. Control Plane GTP header length shall be a multiple of 4 octets. 
Figure 5.1-1 illustrates the format of the GTPv2-C Header. 



Octets 
1 
2 
3 
4 
m-k(m+3) 

n-(n+1) 
(n+2)-(n+3) 



Bits 

5 4 



1 



Version 



I Spare | T | Spare | Spare | Spare 



Message Type 



Message Length (r' Octet) 



Message Length (2"° Octet) 



If T flag is set to 1 , then TEID shall be placed into octets 5- 
8. Otherwise, TEID field is not present at all. 



Sequence Number 



Spare 



Where: 



Figure 5.1-1 : General format of GTPv2 Header for Control Plane 

if T = 0, TEID field is not present, k = 0, m = and n = 5. 

if T = 1, TEID field is present, k = 1, m = 5 and n = 9. 

The usage of GTPv2-C header across EPC specific interfaces is defined in the subclause 5.5 "Usage of the GTPv2-C 
Header". Octet 1 bits shall be coded as follows: 

Bits 6-8 represent the Version field. 

Bit 5 is spare, the sender shall set it to zero and the receiver shall ignore it. 

Bit 4 represents the TEID flag (T). 

Bits 3-1 are spare, the sender shall set it to zero and the receiver shall ignore it. 

5.2 Control Plane GTP Extension Header 

The legacy Extension Header mechanism is not used in GTP version 2 control plane. Future extensions will be 
implemented by adding Information Elements in the message body if new parameters are needed. 



5.3 GTP-C header for Echo and Version Not Supported 
messages 

GTPv2-C message header for Echo Request, Echo Response and Version Not Supported Indication messages shall not 
contain TEID field, but the Sequence Number fields, followed by two spare octets as depicted in figure 5.3-1. The spare 
bits shall be set to zero by the sender and ignored by the receiver. 
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Octets 
1 
2 
3 
4 
5 
6 
7 
8 



8 7 


Bits 

6 5 4 


3 


2 


1 


Version Spare T=0 


Spare 


Spare 


Spare 


Message Type 




Message Length (1^' 


Octet) 








Message Length (2™ 


Octet) 






Sequence Number (1^' Octet) 


Sequence Number (2™ Octet) 


Spare 


Spare 



Figure 5.3-1 : The format of Echo and Version Not Supported message Header 



5.4 EPC specific GTP-C header 



Apart from Echo Request, Echo Response and Version Not Supported Indication messages the GTP-C message header 
shall contain TEID and Sequence Number fields, followed by two spare octets. Typical GTP-C header is depicted in 
figure 5.4-1. The spare bits shall be set to zero by the sender and ignored by the receiver. 



Octets 
1 
2 
3 
4 
5 
6 
7 
8 

g 

10 

11 

12 



Bits 

5 4 



1 



Version 



I Spare | T=1 | Spare | Spare | Spare 



Message Type 



Message Length (r' Octet) 



Tia- 



Message Length (2"° Octet) 



Tunnel Endpoint Identifier (1 Octet) 



wr, 



Tunnel Endpoint Identifier (2"° Octet) 



Tunnel Endpoint Identifier (S'" Octet) 



Tunnel Endpoint Identifier (4 Octet) 



Sequence Number (1 Octet) 



Sequence Number (2"° Octet) 



Spare 



Spare 



Figure 5.4-1 : The format of EPC specific GTPv2 Control Plane message Header 

5.5 Usage of the GTPv2-C Header 

The format of the GTPv2-C header is specified in subclause 5.1 "General format". The usage of the GTP-C header 
across e.g. SlOl ([14]) and Sv ([15]) interfaces are defined in the respective specifications. 

The usage of the GTPv2-C header for EPC specific interfaces is defined below. 

The first octet of the header shall be used is the following way: 

Bits 8-6, which represent GTP-C version shall be set to decimal 2 ('010'). 

Bit 5 is a spare bit. Sending entity shall set it to '0' and the receiving entity shall ignore it. 

Bit 4 represents a 'T' flag, which indicates if TEID field is present in the GTP-C header or not. If 'T' flag is set to 
0, then the TEID field is not present in the GTP-C header at all. If 'T' flag is set to 1, then the TEID field 
immediately follows the Length field in octets 5-8. Apart fro Echo Request and Echo Response messages, in all 
EPC specific messages the value of the 'T' flag shall be set to '1'. 

Bit 3 is a spare bit. Sending entity shall set it to '0' and the receiving entity shall ignore it. 

Bit 2 is a spare bit. Sending entity shall set it to '0' and the receiving entity shall ignore it. 

Bit 1 is a spare bit. Sending entity shall set it to '0' and the receiving entity shall ignore it. 

The usage of the fields in octets 2- n of the header is specified below. 

Octet 2 represents the Message type field, which shall be set to the unique value for each type of control plane 
message. Message type values are specified in Table 6.1-1 "Message types for GTPv2". 
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Octets 2-3 represent the Length field. This field shall indicate the length of the message in octets excluding the 
mandatory part of the GTP-C header (the first 4 octets). The TEID (if present) andSequence Number (if present) 
shall be included in the length count. The format of the Length field is specified in subclause 8.2 "Information 
Element Format". 

For EPC specific interfaces T=l and therefore octets 5-8 represent Tunnel Endpoint Identifier (TEID) field. This 
field shall unambiguously identifies a tunnel endpoint in the receiving GTP-C entity. In the following cases the 
TEID field shall be present in a GTPv2-C header, but its value shall be set to '0': 

Editor's note: a list of the relevant cases should be added here. 

Octets 9-10 represent GTP Sequence Number field. 

The GTP-C header may be followed by subsequent information elements dependent on the type of control plane 

message. 



Octets 

1 -m 
m - n 


8 


7 


Bits 
6 5 4 3 


2 


1 




GTP-C header 




Information Element(s) 















Figure 5.5-1 : GTP-C Header followed by subsequent Information Elements 
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6 GTP-C Message Types and Message Formats 

GTP-C message is sent across GTP control plane tunnel. In a message, GTP-C header is followed by zero or more 
information elements. GTP-C messages are used for the control plane path management, for the control plane tunnel 
management and for mobility management. 

T-PDU is an original packet, for example an IP datagram, from an UE, or from a network node in an external packet 
data network. 

6.1 Message Format and Type values 

GTP defines a set of messages between two associated EPC network elements. The messages to be used are defined in 
the Table 6.1-1. 
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Table 6.1-1 : Message types for GTPv2 



Message Type 
value (Decimal) 


Message 


Reference 


GTP-C 


GTP-U 





Reserved 








1 


Echo Request 




X 


X 


2 


Echo Response 




X 


X 


3 


Version Not Supported Indication 




X 




4-24 


Reserved for SI 01 interface 


TS 29.276 [14] 






25-31 


Reserved for Sv interface 


TS 29.280 [15] 








SGSN/MME to PDN-GW (S4/S1 1 , S5/S8) 








32 


Create Session Request 




X 




33 


Create Session Response 




X 




34 


Update User Plane Request 




X 




35 


Update User Plane Response 




X 




36 


Modify Bearer Request 




X 




37 


IVIodify Bearer Response 




X 




38 


Delete Session Request 




X 




39 


Delete Session Response 




X 




40 


Change Notification Request 




X 




41 


Change Notification Response 




X 




42-63 


For future use 










Messages without explicit response 








64 


IVIodify Bearer Command 
(MME/SGSN to PGW -SI 1/S4, S5/S8) 




X 




65 


IVIodify Bearer Failure Indication 
(PGW to MME/SGSN -S5/S8, S1 1/S4) 




X 




66 


Delete Bearer Command 
(MMEtoPGW-S11,S5/S8) 




X 




67 


Delete Bearer Failure Indication (PGW to MME -S5/S8, S1 1) 




X 




68 


Bearer Resource Command 
(MME/SGSN to PGW -SI 1/S4, S5/S8) 




X 




69 


Bearer Resource Failure Indication 
(PGW to MME/SGSN -S5/S8, S1 1/S4) 




X 




70 


Downlink Data Notification Failure Indication (SGSN/MME to 
SGW-S4/S11) 




X 




71-94 


For future use 










PDN-GW to SGSN/MME (S5/S8, S4/S11) 








95 


Create Bearer Request 




X 




96 


Create Bearer Response 




X 




97 


Update Bearer Request 




X 




98 


Update Bearer Response 




X 




99 


Delete Bearer Request 




X 




100 


Delete Bearer Response 




X 




101-127 


For future use 










MME to MME, SGSN to MME, MME to SGSN, SGSN to 
SGSN(S3/10/S16) 








128 


Identification Request 




X 




129 


Identification Response 




X 




130 


Context Request 




X 




131 


Context Response 




X 




132 


Context Acknowledge 




X 




133 


Forward Relocation Request 




X 




134 


Forward Relocation Response 




X 




135 


Forward Relocation Complete Notification 




X 




136 


Forward Relocation Complete Acknowledge 




X 




137 


Forward SRNS Context Notification 




X 




138 


Forward SRNS Context Acknowledge 




X 




139 


Relocation Cancel Request 




X 




140 


Relocation Cancel Response 




X 




141-148 


For future use 










SGSN to MME, MME to SGSN (S3) 








149 


Detach Notification 




X 




150 


Detach Acknowledge 




X 




151 


CS Paging Indication 




X 




152-159 


For future use 
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Message Type 
value (Decimal) 


Message 


Reference 


GTP-C 


GTP-U 




MMEtoSGW(SII) 








160 


Create Forwarding Tunnel Request 




X 




161 


Create Forwarding Tunnel Response 




X 




162 


Suspend Notification 




X 




163 


Suspend Acknowledge 




X 




164 


Resume Notification 




X 




165 


Resume Acknowledge 




X 




166 


Create Indirect Data Forwarding Tunnel Request 




X 




167 


Create Indirect Data Forwarding Tunnel Response 




X 




168-175 


For future use 










SGWtoSGSN/MME(S4/S11) 








176 


Downlink Data Notification 




X 




177 


Downlink Data Notification Acknowledgement 




X 




178 


Update Bearer Complete 




X 




179-191 


For future use 










Other 








192-244 


For future use 








245-255 


Reserved for GTP-U 


TS 29.281 [13] 




X 



6.1 .1 Presence requirements of Information Elements 

There are three different presence requirements (Mandatory, Conditional, or Optional) for an IE within a given GTP- 
PDU: 

Mandatory means that the IE shall be included by the sending side, and that the receiver diagnoses a "Mandatory 
IE missing" error when detecting that the IE is not present. A response including a "Mandatory IE missing" 
cause, shall include the type of the missing IE. 

Conditional means: 

• that inclusion of the IE by the sender depends on conditions specified in the relevant protocol specification; 

Editor's Note: the receiver shall check the conditions as specified in the corresponding message type description, 

based on the parameter combination in the message and/or on the state of the receiving node, to infer if a 
conditional IE shall be expected. Only if a conditional IE, which is absolutely necessary for the receiving 
entity to complete the procedure, is missing, then the receiver shall abort the procedure. 

Optional means that the IE shall be included as a service option. Therefore, the IE may be included or not in a 
message. 

For conditional lEs, the clause describing the GTP-PDU explicitly defines the conditions under which each IE becomes 
mandatory or optional for that particular GTP-PDU. These conditions shall be defined so that the presence of a 
conditional IE only becomes mandatory if it is critical for the receiving entity. The definition might reference other 
protocol specifications for final terms used as part of the condition. 

Editor's Note: This definition of conditions shall be done per conditional IE in a dedicated column of the table 
Usting the lEs for that GTP-PDU. 

6.1 .2 Comprehension requirements for Information Elements 

For future extensibility of the GTP-C protocol, it shall be possible to add new mandatory and conditional Information 
Element (IE) types to the existing messages. 

Editor's note: It is FFS if these requirements would apply also to GTP-U. 

For the legacy GTPv2 entity such lEs will be unexpected, but will be treated as optional lEs. That is, the lEs of known 
type will be processed and the lEs of unknown or unexpected type will be silently discarded. 

In future updates to the existing procedures it may become required that the sending entity is aware if the new 
mandatory or conditional IE was comprehended by the receiver, or not. 
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In order to support future types, a field "Comprehension Required" (CR) shall be included as part of the common header 
of each IE (see subclause 8.2). 

An Endpoint Receiver is the ultimate receiver of the specific GTP-C message (e.g. a P-GW for a Create Session 
Request message, or a MME or a S4-SGSN for a Create Session Response message, or a S-GW for a Update User Plane 
Request message). 

An Intermediate Node is a node that handles GTP-C but is not the ultimate endpoint of the specific GTP-C message 
(e.g. an S-GW for a Create Session Request message). 

A CR field is defined as part of the Information element header as a 3 bits decimal scalar field which shall have the 
following values. This field shall be set by the sending node as follows: 



CR 


Defined Behaviour Behaviour of the Receiving Node 





No comprehension shall be required of the receiving node and therefore no explicit behaviour is 
required for the understanding of the IE. 


1 


This Information Element shall be comprehended by the receiving node. 

For a Request message: if the receiving GTP entity cannot comprehend the IE while the 

comprehension is required by the CR flag, then the receiver shall discard the request, should log the 

error, and shall send a response with an appropriate Cause value. 

For a Response message: if the receiving GTP entity cannot comprehend the IE while the 

comprehension is required by the CR flag, then the receiver shall notify the upper layer that a 

message with this unknown or unexpected IE has been received and should log the error. 


2-7 


Reserved 



Figure 6.1.2-1 : Definition of Comprehension Required Flag of thefor Information Elements 

Editor's note: it is EPS if Cause should be amended by complete IE or only its Type. 

Editor's Note: It is for further study if a rejected Response message shall lead to an error notification back to the 
sender. Rejected Request messages shall always include an appropriate rejection cause value in the 
corresponding Response, but this can be added to the normative text, here or in clause 9.1, once the 
handling of Response messages is decided. 

6.1.3 Grouped Information Elements 

Information elements can contain other lEs. This type of IE is called "Grouped lEs". 

Grouped lEs have a length value in the TLIV encoding, which includes the added length of all the embedded lEs plus 
the length of any other, non-TLIV -encoded, value fields. Example: 



Type 



Length 



Type 



Length 



Type Length 





9+?(+y 


3 octets fiijld 




X 






y 





V. 



~>^ 



First embedded IE 



_y 



_^ 



Second embedded IE 



Grouped IE 

Figure 6.1.3-1: Grouped IE format 

In this example, the first value field, marked as "3 octets field", represents a field which is not a TLIV encoded GTP IE. 

In order to provide the flexibility of having optional or conditional embedded lEs, as well as a variable number of them, 
it is required that all non-TLIV-encoded fields are the beginning of the grouped IE. After the last defined non-TLIV- 
encoded field, only embedded TLIV -encoded lEs might follow. 

The flexibility of having optional, conditional or a variable number of embedded fields within an IE is not provided by 
non-grouped lEs and it is due to the usage of TLIV encoded fields. This flexibility also allows using one and the same 
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type of grouped lEs for different messages and slightly different purposes, as long as the main purpose of the IE type is 
the same. It is encouraged to define grouped IBs in a flexible way to minimize the number of types needed. 

Grouped IBs are not marked by any flag or limited to a specific range of IB type values. The clause describing an IB in 
this specification shall explicitly state if it is grouped. 

NOTB: Bach entry into each Grouped IB creates a new scope level. Bxit from the grouped IB closes the scope 
level. The GTPv2 message level is the top most scope. This is analogous to the local scope of a 
subroutine/function. 

6.1 .4 Information Element instance 

Every GTPv2 message and grouped IB within a message in this specification has a column documenting the instance 
value of each IB. 

When a GTPv2 message is encoded for use the instance value of each included IB is encoded in the Instance field of the 
IE for the message scope. See clause 7 and subclause 8.2 for details of that encoding. 

An Information Element in an encoded GTPv2 message or encoded grouped IE is identified by the pair of IB Type and 
Instance values and described by a specific row in the corresponding tables in subclauses of 7 in the present document. 

If several Information Elements with the same Type and Instance values are included in an encoded GTPv2 message, 
they represent a list for the corresponding IB name and row identified in the message grammar in subclauses of clause 
7. 

If several Information Elements with the same Type and Instance values are included in an encoded grouped IE, they 
represent a list for the corresponding IE name and row identified in the grouped IE grammar in subclauses of clause 7. 

In tables in this document the instance value for "Private Extension" is marked as VS (Vendor Specific). While an 
instance value must be encoded by the sender the value can be Vendor and even Private Extension specific. 

The same IB name might be used in different messages (on the top level or within grouped IBs) in this specification. 
The instance value and name of an IB is only meaningful within the scope of the message definition . The combination 
of Type value and Instance value uniquely identifies a specific row in a message description table. 

6.4 Message Granularity 

The GTPv2-C messages shall be sent per UB on the S3, SIO and S16 interfaces. 

The GTPv2-C messages shall be sent per PDN-Connection on the S4 and S 1 1 interfaces apart from the following 
exclusion. 

The following GTPv2-C messages are sent per UB on the S4 and SI 1 interfaces: 

- Downlink Data Notification/ Acknowledgement 

- Stop Paging 
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7 GTP-C messages 

7.1 Path Management Messages 

Three path management messages are specified for GTP-C: Echo Request, Echo Response and Version Not Supported 
Indication. 

7.1.1 Echo Request 

3GPP TS 23.007 [17] specifies that a GTP-C entity may send an Echo Request to find out if the peer entity is aHve. 
When and how often an Echo Request message may be sent is implementation specific but an Echo Request shall not be 
sent more often than every 60 s on each path. This does not prevent resending an Echo Request with the same sequence 
number according to the T3-RESPONSE timer. 

As an implementation option, it is recommended that Echo Request should be sent only when a GTP-C entity has not 
received any GTP response message for a previously sent request message on the GTP-C path for the above specified, 
implementation dependent period of time. 

Table 7.1.1-1 specifies the information elements included in the Echo Request message. 

The optional Private Extension contains vendor or operator specific information. 

Table 7.1.1-1: Information Element in Echo Request 



Information elements 


P 


Condition / Comment 


CR 


IE Type 


Recovery 


M 


None 


1 


Recovery 


Private Extension 





None 





Private 
Extension 



7.1.2 Echo Response 



3GPP TS 23.007 [17] specifies that a GTP-C entity shall be prepared to receive an Echo Request at any time and it shall 
reply with an Echo Response. 

Table 7.1.2-1 specifies the information elements included in the Echo Response message. 

The Recovery information element contains the local Restart Counter, which is specified in 3GPP TS 23.007 [17]) 

The optional Private Extension contains vendor or operator specific information. 

Table 7.1.2-1 : Information Element in Echo Response 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Recovery 


M 


None 


1 







Private Extension 





None 





Private Extension 


vs 



7.1 .3 Version Not Supported Indication 

This message contains only the GTPv2 header and indicates the latest GTP version that the sending entity supports. 

7.2 Tunnel Management Messages 

A node shall include the Recovery information element if it is in contact with the peer for the first time or the node has 
restarted recently and the new Restart Counter value has not yet been indicated to the peer. The peer receiving the 
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Recovery information element shall handle it as when an Echo Response message is received but shall consider the rest 
of the message in accordance with the message semantics and parameters. 

Editor's Note: The CSID Information Element for partial failure handling is specified for some of the messages. The 
rest of the messages that may need to carry the CSID IE are FFS. 

7.2.1 Create Session Request 

The Create Session Request message shall be sent on the SI 1 interface by the MME to the SGW, and on the S5/S8 
interface by the SGW to the PGW as part of the procedures: 

- E-UTRAN Initial Attach 

UE requested PDN connectivity 
The message shall also be sent on the S 1 1 interface by the MME to the SGW as part of the procedures: 
Tracking Area Update procedure with Serving GW change 
S1/X2 -based handover with SGW change 

- UTRAN lu mode to E-UTRAN Inter RAT handover with SGW change 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover with SGW change 
and on the S4 interface by the SGSN to the SGW as part of the procedures: 

Routing Area Update with MME interaction and with SGW change 

- E-UTRAN to UTRAN lu mode Inter RAT handover with SGW change 

- E-UTRAN to GERAN A/Gb mode hiter RAT handover with SGW change 
Serving RNS relocation 

Combined hard handover and SRNS relocation 

- Combined Cell / URA update and SRNS relocation 
Enhanced serving RNS relocation with SGW relocation 
PDP Context activation 



ETSI 



3GPP TS 29.274 version 8.0.0 Release 8 



24 



ETSI TS 129 274 V8.0.0 (2009-01) 



Table 7.2.1-1 : Information Elements in a Create Session Request 



Information elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


IMSI 


M 


None 


1 


IMSI 





MSISDN 


C 


In case of E-UTRAN Initial Attach it shall be included on S1 1 if 

provided in the subscription data from the HSS and it shall be 

included on 

S5/S8 if provided by the MME 

In case of UE Requested PDN Connectivity it shall be included if the 

MME has it stored for that UE 


1 


MSISDN 





ME Identity (MEI) 


C 


The MME shall include ME Identity (MEI) IE, if available. 


1 


MEI 





User Location Info (ULI) 


C 


Shall be included for E-UTRAN initial attach and UE requested PDN 
connectivity. 


1 


ULI 





Serving Network 


C 


Shall be included for E-UTRAN initial attach and UE requested PDN 
connectivity. 


1 


Serving Network 





RAT Type 


M 


None 


1 


RAT Type 





Indication Flags 


M 


Applicable flags: 

S5/S8 Protocol Indicator: shall be used on S11/S4 and set according 

to the protocol chosen to be used on S5/S8 

Dual Address Bearer Flag: shall be set to 1 when the UE requests 

PDN type IPv4v6 and all SGSNs which the UE may be handed over 

to support dual addressing, which is determined based on node pre- 

configuration by the operator 

Handover Indication: shall be set in E-UTRAN Initial Attach or in UE 

Requested PDN Connectivity if the UE comes from non-3GPP 

access 

Operation Indication: shall be set in TAU/RAU 


1 


Indication 





Sender F-TEID for 
Control Plane 


M 


None 




F-TEID 





PGW S5/S8 Address for 
Control Plane or PMIP 


C 


Shall be sent on S1 1 / S4. TEID or GRE Key is set to "0" in the E- 
UTRAN initial attach and UE requested PDN connectivity 
procedures. 




F-TEID 


1 


Access Point Name 
(APN) 


C 


Shall be included for E-UTRAN initial attach and UE requested PDN 
connectivity. 




APN 





Selection Mode 


C 


Shall be included for E-UTRAN initial attach and UE requested PDN 
connectivity. It indicates whether a subscribed APN or a non 
subscribed APN chosen by the MME was selected. 




Selection Mode 





PDN Type 


M 


Shall be set to IPv4, IPv6 or IPv4v6, This is based on the 
subscription record retrieved from the HSS. 




PDN Type 





PDN Address Allocation 
(PAA) 


C 


Included for E-UTRAN initial attach and UE requested PDN 
connectivity. 

The PDN type field in the PAA is set based on the UE request. 
In case of static IP address assignment, the MME shall set the IPv4 
address and/or IPv6 prefix length and IPv6 address if available. 
If static IP address assignment is not used, the the IPv4 address 
shall be set to 0.0.0.0, and IPv6 Prefix Length and IPv6 address shall 
all be set to zero. 




PAA 





Maximum APN 
Restriction 


M 


Denotes the most stringent restriction as required by any already 
active bearer context. If there are no already active bearer contexts, 
this value is set to the least restrictive type 


1 


APN Restriction 





Aggregate Maximum Bit 
Rate (APN-AMBR) 


C 


This IE represents the APN-AMBR. It shall be included for E-UTRAN 
initial attach and UE requested PDN connectivity. 


1 


AMBR 





Protocol Configuration 
Options (PCO) 





Not applicable to TAU/RAU/Handover 


1 


PCO 





Bearer Contexts 


M 


Several lEs with this type and instance values shall be included as 

necessary to represent a list of Bearers. 

One bearer shall be included for "eUTRAN Initial Attach" or "UE 

requested PDN Connectivity"; 

One or more bearers shall be included for Handover/TAU with SGW 

change 


1 


Bearer Context 





Bearer Contexts to be 
removed 


C 


Shall be included on S4/S1 1 in mobility cases where any of the 
bearers existing before the mobility procedure will be deactived as 
consequence of the mobility procedure. 

For each of those bearers an IE with this type and instance values 
shall be included. 


1 


Bearer Context 


1 


Trace Information 


C 


This IE includes Trace Reference, Trace Type, Trigger Id, OMC 

Identity. 

Shall be included if SGW and/or PGW is activated [1 8]. 


1 


Trace Information 





Recovery 


C 


Included if contacting the peer for the first time 


1 


Recovery 





MME-CSID 





Optionally included by MME on S1 1 . Shall be forwarded by SGW on 
S5/S8. Only one value may be present per PDN connection 


1 


CSID 





SGW-CSID 





Optionally included by SGW on S5/S8. Only one value may be 
present per PDN connection. 


1 


CSID 


1 


Private Extension 





None 





Private Extension 


vs 
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Table 7.2.1-2: Bearer Context to be createdwithin Create Session Request 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 




EBI 





ULTFT 





None 




Bearer TFT 





DLTFT 





None 




Bearer TFT 


1 


S1-UeNodeBF-TEID 


C 


Shall be included on S1 1 at eUTRAN handover/TAU 




F-TEID 





S4-U SGSN F-TEID 


C 


Shall be included on S4 




F-TEID 


1 


S5/8-U SGW F-TEID 


C 


Included on S5/S8 at "eUTRAN Initial Attach" or "UE 
Requested PDN Connectivity" 




F-TEID 


2 


Bearer Level QoS 


M 


None 




Bearer QoS 





Charging 
Characteristics 


C 


Shall be included according to 3GPP TS 32.251 [8] 




Charging 
Characteristics 





Bearer Flags 





Applicable flags: 

• PPC (Prohibit Payload Compression) 


1 


Bearer Flags 






Table 7.2.1-3: Bearer Context to be removed within Create Session Request 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 


1 


EBI 





S4-U SGSN F-TEID 


C 


Shall be sent on S4 


1 


F-TEID 


1 



7.2.2 Create Session Response 



The Create Session Response message shall be sent on the Sll interface by the SGW to the MME, and on the S5/S8 
interface by the PGW to the SGW as part of the procedures: 

- E-UTRAN Initial Attach 

UE requested PDN connectivity 
The message shall also be sent on the Sll interface by the SGW to the MME as part of the procedures: 
Tracking Area Update procedure with Serving GW change 
S1/X2 -based handover with SGW change 

- UTRAN lu mode to E-UTRAN Inter RAT handover with SGW change 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover with SGW change 
and on the S4 interface by the SGW to the SGSN as part of the procedures: 

Routing Area Update with MME interaction and with SGW change 

- E-UTRAN to UTRAN lu mode Inter RAT handover with SGW change 

- E-UTRAN to GERAN A/Gb mode Inter RAT handover with SGW change 
Serving RNS relocation 

Combined hard handover and SRNS relocation 

- Combined Cell / URA update and SRNS relocation 
Enhanced serving RNS relocation with SGW relocation 
PDF Context activation 
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Table 7.2.2-1 : Information Elements in a Create Session Response 



Information 
elements 


P 


Condition / Comment 


OR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





BCM 


C 


Shall be included if this message is part of the procedure 
PDP Context Activation using S4 


1 


Bearer Control 
Mode 





Change Reporting 
Action 


C 


Shall be sent on S4 if the IVIS Info Change Reporting 
mechanism is to be used for this subscriber in the SGSN 


1 


Change Reporting 
Action 





Sender F-TEID for 
Control Plane 


c 


Shall be sent on S1 1 . On S5/S8 it is not needed because 
its content would be identical to the IE PGW S5/S8 
Address for Control Plane or PIVIIP 


1 


F-TEID 





PGW S5/S8 Address 
for Control Plane or 
PMIP 


M 


Shall include the TEID in the GTP based S5/S8 case and 
the GRE key in the PIVIIP based S5/S8 case. 


1 


F-TEID 


1 


PDN Address 
Allocation (PAA) 


c 


Shall be included for E-UTRAN initial attach and UE 
requested PDN connectivity. 


1 


PAA 





APN Restriction 


M 


Denotes the restriction on the combination of types of APN 
for the APN associated with this EPS bearer Context. 


1 


APN Restriction 





Aggregate Maximum 
Bit Rate (APN-AMBR) 


C 


This IE represents the APN-AMBR. Shall be included if the 
received APN-AMBR has been modified by the PCRF 


1 


AMBR 





Protocol 

Configuration Options 
(PCO) 





Not applicable to TAU/RAU 


1 


PCO 





Bearer Contexts 
created 


M 


Several lEs with this type and instance values shall be 

included as necessary to represent a list of Bearers. 

One bearer shall be included for "eUTRAN Initial Attach" or 

"UE Requested PDN Connectivity" 

One or more created bearers shall be included for 

Handover/TAU with SGW change 


1 


Bearer Context 





Bearer Contexts 
marked for removal 


C 


Shall be included on S4/S1 1 in mobility cases where any of 
the bearers existing before the mobility procedure will be 
deactived as consequence of the mobility procedure. 
For each of those bearers an IE with this type and instance 
values shall be included. 


1 


Bearer Context 


1 


Trace Information 


c 


This IE includes Trace Reference, Trace Type, Trigger Id, 

OMC Identity. 

Shall be included if SGW and/or PGW is activated [18].. 


1 


Trace Information 





Recovery 


c 


Shall be included If contacting the peer for the first time 


1 


Recovery 





PGW-CSID 





Optionally included by PGW on S5/S8. Shall be forwarded 
by SGW on S1 1 . Only one value may be present per PDN 
connection 


1 


CSID 


2 


SGW-CSID 





Optionally included by SGW on S1 1 . Only one value may 
be present per PDN connection. 


1 


CSID 


1 


Private Extension 





None 





Private Extension 


VS 
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Table 7.2.2-2: Bearer Context Createdwithin Create Session Response 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 




EBI 





Cause 


M 


Indicates if the bearer handling was successful, and if not, 
gives information on the reason. 




Cause 





ULTFT 





None 




Bearer TFT 





DLTFT 





None 




Bearer TFT 


1 


S1-USGWF-TEID 


C 


Shall be included on S1 1 if SI is used 




F-TEID 





S4-U SGW F-TEID 


C 


Shall be included on S1 1 if S4 is used 




F-TEID 


1 


S5/8-U PGW F-TEID 


C 


Included in "eUTRAN Initial Attach" or "UE Requested 
PDN Connectivity 




F-TEID 


2 


S12 SGW F-TEID 


C 


Shall be included on S1 1 if S12 is used 




F-TEID 


3 


Bearer Level QoS 


C 


Shall be included if the received QoS parameters have 
been modified 




Bearer QoS 





Charging Id 


M 


None 




Charging Id 





Bearer Flags 





Applicable flags: 

• PPC (Prohibit Payload Compression) 




Bearer Flags 






Table 7.2.2-3: Bearer Context marked to be removed within Create Session Response 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 


1 


EBI 





Cause 


M 


Indicates if the bearer handling was successful, and if not, 
gives information on the reason. 


1 


Cause 






7.2.3 Create Bearer Request 

The Create Bearer Request message shall be sent on the S5/S8 interface by the PGW to the SGW and on the SI 1 
interface by the SGW to the MME as part of the Dedicated Bearer Activation procedure. 

The message shall also be sent on the S5/S8 interface by the PGW to the SGW and on the S4 interface by the SGW to 
the SGSN as part of the Secondary PDP Context Activation procedure or the Network Requested Secondary PDP 
Context Activation procedure. 
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Table 7.2.3-1 : Information Elements in a Create Bearer Request 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Procedure 
Transaction Id (PTI) 


C 


Shall besent when the procedure was initiated by a UE 
Requested Bearer Resource IVIodification Procedure. 
PTI shall be the same as the one used in the 
corresponding Bearer Resource Command 


1 


RAT Type 





Linked Bearer Identity 
(LBI) 


M 


Used to identify the PDN connection 




EBl 





APN Aggregate 
IVIaximum Bit Rate 
(APN-AMBR) 


C 


This IE shall be included when the P-GW initiates a create 
bearer procedure in case of policy updates due to the 
creation of non GBR flows 




AMBR 





Protocol 

Configuration Options 
(PCO) 





None 




PCO 





Bearer Contexts 


M 


Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 




Bearer Context 





PGW-CSID 





Optionally included by PGW on S5/S8. Shall be forwarded 
by SGW on S1 1 . Only one value may be present per PDN 
connection 




CSID 


2 


SGW-CSID 





Optionally included by SGW on S1 1 . Only one value may 
be present per PDN connection. 




CSID 


1 


Private Extension 





None 





Private Extension 


vs 



Table 7.2.3-2: Bearer Context within Create Bearer Request 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


Shall be set to 




EBl 





ULTFT 


M 


None 




Bearer TFT 





DLTFT 


C 


Shall be sent for PMIP based S5/S8 




Bearer TFT 


1 


S1-USGWF-TEID 


C 


Shall be sent on S1 1 if the S1 -U interface is used 




F-TEID 





S5/8-U PGW F-TEID 


c 


Shall be sent on S5/S8 




F-TEID 


1 


S12SGWF-TEID 


c 


Shall be sent on S4 if the S12 interface is used 




F-TEID 


2 


Bearer Level QoS 


M 


None 




Bearer QoS 





Charging 
Characteristics 


c 


Shall be included according to 3GPP TS 32.251 [8] 




Charging 
Characteristics 





Charging Id 


M 


None 




Charging Id 





Bearer Flags 





Applicable flags: 

• PPC (Prohibit Payload Compression) 




Bearer Flags 






7.2.4 Create Bearer Response 



The Create Bearer Response message shall be sent on the S5/S8 interface by the SGW to the PGW, and on the SI 1 
interface by the MME to the SGW as part of the Dedicated Bearer Activation procedure. 

The message shall also be sent on the S5/S8 interface by the SGW to the PGW and on the S4 interface by the SGSN to 
the SGW as part of Secondary PDP Context Activation procedure or the Network Requested Secondary PDP Context 
Activation procedure. 
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Table 7.2.4-1 : Information Elements in a Create Bearer Response 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





Bearer Contexts 


M 


Several IBs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 


1 


Bearer Context 





MME-CSID 





Optionally included by MME on S1 1 . Shall be forwarded by 
SGW on S5/S8. Only one value may be present per PDN 
connection 


1 


CSID 





SGW-CSID 





Optionally included by SGW on S5/S8. Only one value 
may be present per PDN connection. 


1 


CSID 


1 


Private Extension 





None 





Private Extension 


vs 



Table 7.2.4-2: Bearer Context within Create Bearer Response 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 




EBI 





Cause 


M 


Indicates if the bearer handling was successful, and if not, 
gives information on the reason. 




Cause 





S1 eNodeB F-TEID 


C 


Shall be sent on S1 1 if the S1 -U interface is used 




F-TEID 





S1 SGW F-TEID 


C 


Shall be sent on S1 1 . It may be used to correlate the 
bearers with those in the Create Bearer Request 




F-TEID 


1 


S5/8-U SGW F-TEID 


C 


Shall be sent on S5/S8 




F-TEID 


2 


S5/8-U PGW F-TEID 


C 


Shall be sent on S5/S8. It may be used to correlate the 
bearers with those in the Create Bearer Request 




F-TEID 


3 


S12RNC F-TEID 


C 


Shall be sent on S4 if the S12 interface is used 


1 


F-TEID 


4 



7.2.5 Bearer Resource Command 

A Bearer Resource Command message shall be sent from a MME to a SGW and forwarded to PGW as a part of the UE 
requested bearer resource modification procedure. 

The message shall also be sent on S4 interface by a SGSN to a SGW and on S5/S8 interface by a SGW to a PGW as 
part of MS initiated modification procedure, secondary PDP context activation procedure. 

Table 7.2.5—1 specifies the presence of the lEs in the message. 

Table 7.2.5-1 : Information Elements in a Bearer Resource Command 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 














Linked EPS Bearer ID 
(LBI) 


M 


None 


1 


LBI 





Procedure 
Transaction Id (PTI) 


M 


None 


1 


PTI 





Flow Quality of 
Service (Flow OoS) 


C 


Not included for Bearer resource release. 


1 


Flow QoS 





Traffic Aggregate 
Description (TAD) 


M 


The TAD consists of the description of the packet filter(s) 
for traffic flow aggregate. 


1 


TAD 





Private Extension 





None 





Private Extension 


vs 



7.2.6 Bearer Resource Failure Indication 

A Bearer Resource Failure Indication shall be sent by PGW to SGW and forwarded to MME to indicate failure of UE 
requested bearer resource modification procedure. 
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The message shall also be sent by a PGW to a SGW and forwarded to a SGSN as part of failure of MS initiated 
modification procedure, secondary PDP context activation procedure. 

Table 7.2.6-1 specifies the presence of the lEs in the message. 

Possible Cause values are: 

"No resources available". 

"No memory is available". 

"Missing or unknown APN". 

"User authentication failed". 

"System failure". 

"Semantic error in the TAD operation". 

"Syntactic error in the TAD operation". 

"Semantic errors in packet filter(s)". 

"Syntactic errors in packet filters(s)". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Optional IE incorrect". 

"Invalid message format". 

"APN access denied - no subscription". 

Table 7.2.6-1 : Information Elements in a Bearer Resource Failure Indication 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





Linked EPS Bearer ID 


M 


None 


1 


EBI 





Procedure 
Transaction ID (PTI) 


M 


None 


1 


PTI 





Recovery 





None 


1 


Recovery 





Private Extension 





None 





Private Extension 


vs 



7.2.7 Modify Bearer Request 



The Modify Bearer Request message is sent on SI 1 by the MME to the SGW and on S5/S8 by the SGW to the PGW as 
part of the procedures: 

- E-UTRAN Tracking Area Update without SGW Change 
UE triggered Service Request 

Inter eNodeB handover with MME relocation 

- UTRAN lu mode to E-UTRAN Inter RAT handover 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover 
UE requested PDN connectivity 

3G SGSN to MME combined hard handover and SRNS relocation procedure 
It is also sent on S4 by the SGSN to the SGW and on S5/S8 by the SGW to the PGW as part of the procedures: 
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Routeing Area Update with MME interaction and without SGW change 
Routeing Area Update with MME interaction and with SGW change 

- Inter SGSN Routeing Area Update Procedure and Combined Inter SGSN RA / LA Update to S4 SGSNs 

- Combined RA / LA Update in the Case of Inter SGSN RA Update Procedure 
lu mode RA Update Procedure 

Serving RNS Relocation Procedure 

Combined Hard Handover and SRNS Relocation Procedure 

- Combined Cell / URA Update and SRNS Relocation Procedure 
Enhanced Serving RNS Relocation without SGW relocation 
UE Initiated Service Request Procedure 

- lu mode to A/Gb mode Intra SGSN Change 

- A/Gb mode to lu mode Intra SGSN Change 

- lu mode to A/Gb mode Inter-SGSN Change 

- A/Gb mode to lu mode Inter-SGSN Change 

Paging Response with no established user plane on S4 
PDP Context Activation Procedure 
on S4 by the SGSN to the SGW as part of: 

- READY to STANDBY transition within the network 
RAB Release Procedure 

lu Release Procedure 
RAB Assignment Procedure 
on S 1 1 by the MME to the SGW as part of: 

- E-UTRAN Initial Attach 
S 1 release procedure 

and on S5/S8 by the SGW to the PGW as part of: 

Tracking Area Update procedure with Serving GW change 

Inter eNodeB handover without MME relocation, with Serving GW relocation 

- E-UTRAN to UTRAN lu mode Inter RAT handover 

- E-UTRAN to GERAN A/Gb mode Inter RAT handover 

- Gn/Gp SGSN to MME Tracking Area Update 
Enhanced Serving RNS Relocation with SGW relocation 
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Table 7.2.7-1 : Information Elements in a Modify Bearer Request 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


ME Identity (MEI) 


C 


Shall be sent on S5/S8 in case of Gn/Gp SGSN to MME 
TAU 


1 


MEI 





User Location Info 
(ULI) 





None 


1 


ULI 





Serving Network 


c 


Shall be sent in case of TAU with MME change 
Sent in case of RAU with MME interaction 


1 


Serving Network 





RAT Type 


c 


Shall be sent on S1 1 in case of TAU with MME change, 
UE triggered Service Request and l-RAT Handover. 
Shall be sent on S5/S8 in case of RAT type change. 
Shall be sent on S4 in case of RAU with MME interaction 


1 


RAT Type 





Indication Flags 


M 


Applicable flags: 

• ISRAI: Shall be used on S1 1 in case of TAU 
without MME change and in case of IRAT 
handover. Shall be used on S4 in case of RAU 
with MME interaction 

• Handover Indication: Shall be set in E-UTRAN 
Initial Attach or in UE Requested PDN 
Connectivity if the UE comes from non-3GPP 
access 

• Scope Indication: Shall be used on S1 1 in case of 
S1 release procedure to release all S1-U bearers 
for the UE 


1 


Indication 





Sender F-TEID for 
Control Plane 


C 


Shall be sent on S11 


1 


F-TEID 





PGW S5/S8 Address 
for Control Plane or 
PMIP 


C 


Shall be sent on S1 1 in case of Handover or TAU 


1 


F-TEID 


1 


Aggregate Maximum 
Bit Rate (APN-AMBR) 


c 


APN-AMBR shall be sent in case of 3G SGSN to MME 
combined hard handover and SRNS relocation procedure 


1 


AMBR 





Delay Downlink 
Packet Notification 
Request 


c 


Shall be sent on S1 1 in case of UE triggered Service 
Request 


1 


Delay Value 





Bearer Contexts to be 
modified 


c 


Shall be sent if the indication flag "Scope Indication" Is not 

set. 

Several lEs with this type and instance values shall be 

included as necessary to represent a list of Bearers to be 

modified 


1 


Bearer Context 





Bearer Contexts to be 
removed 


c 


Shall be included on S4/S1 1 in mobility cases where any of 
the bearers existing before the mobility procedure will be 
deactived as consequence of the mobility procedure. 
For each of those bearers an IE with this type and instance 
values shall be included. 


1 


Bearer Context 


1 


Recovery 


c 


Included if contacting the peer for the first time 


1 


Recovery 





Private Extension 





None 





Private Extension 


vs 
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Table 7.2.7-2: Bearer Context to be modified within IVIodify Bearer Request 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 


1 


EBI 





NSAPI 


C 


Sent in case of 3G SGSN to MIVIE combined hard 
handover and SRNS relocation procedure 


1 


NSAPI 





S1 eNodeB F-TEID 


C 


Sent on S1 1 if S1 -U is being used: 

• at OUTRAN initial attach 

• at UE triggered Service Request 

• in all handover cases 


1 


F-TEID 





S5/8-U SGW F-TEID 


C 


Sent on S5/S8 at Handover or TAU 


1 


F-TEID 


1 


S5/8-U PGW F-TEID 


C 


Handover/TAU (S1 1) in case of GTP based S5/S8 
IRAT-Handover (S1 1 ) In case of GTP based S5/S8 


1 


F-TEID 


2 


S12RNC F-TEID 


C 


Sent on S1 1 if S1 2 is being used 


1 


F-TEID 


3 


Bearer Level QoS 


C 


Sent on S1 1 at TAU without SGW change 


1 


Bearer QoS 





Charging 
Characteristics 


c 


To be included according to 3GPP TS 32.251 [8] 


1 


Charging 
Characteristics 





Charging Id 


c 


Sent on S1 1 in case of SGW change 


1 


Charging Id 






Table 7.2.7-3: Bearer Context to be removed withiin IVIodify Bearer Request 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 


1 


EBI 






7.2.8 Modify Bearer Response 

The Modify Bearer Request message is sent on SI 1 by the SGW to the MME and on S5/S8 by the PGW to the SGW as 
part of the procedures: 

- E-UTRAN Tracking Area Update without SGW Change 
UE triggered Service Request 

Inter eNodeB handover with MME relocation 

- UTRAN lu mode to E-UTRAN Inter RAT handover 

- GERAN A/Gb mode to E-UTRAN Inter RAT handover 
UE requested PDN connectivity 

3G SGSN to MME combined hard handover and SRNS relocation procedure 
It is also sent on S4 by the SGW to the SGSN and on S5/S8 by the PGW to the SGW as part of the procedures: 
Routeing Area Update with MME interaction and without SGW change 
Routeing Area Update with MME interaction and with SGW change 

- Inter SGSN Routeing Area Update Procedure and Combined Inter SGSN RA / LA Update to S4 SGSNs 

- Combined RA / LA Update in the Case of Inter SGSN RA Update Procedure 
lu mode RA Update Procedure 

Serving RNS Relocation Procedure 

- Combined Hard Handover and SRNS Relocation Procedure 
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- Combined Cell / URA Update and SRNS Relocation Procedure 
Enhanced Serving RNS Relocation without SGW relocation 
UE Initiated Service Request Procedure 

- lu mode to A/Gb mode Intra SGSN Change 

- A/Gb mode to lu mode Intra SGSN Change 

- lu mode to A/Gb mode Inter-SGSN Change 

- A/Gb mode to lu mode Inter-SGSN Change 

Paging Response with no established user plane on S4 
PDP Context Activation Procedure 
on S 1 1 by the SGW to the MME as part of: 

- E-UTRAN Initial Attach 
S 1 release procedure 

on S4 by the SGSN to the SGW as part of: 

- READY to STANDBY transition within the network 
RAB Release Procedure 

lu Release Procedure 
RAB Assignment Procedure 
and on S5/S8 by the PGW to the SGW as part of: 

Tracking Area Update procedure with Serving GW change 

Inter eNodeB handover without MME relocation, with Serving GW relocation 

- E-UTRAN to UTRAN lu mode Inter RAT handover 

- E-UTRAN to GERAN A/Gb mode Inter RAT handover 

- Gn/Gp SGSN to MME Tracking Area Update 
Enhanced Serving RNS Relocation with SGW relocation 
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Table 7.2.8-1 : Information Elements in a Modify Bearer Response 



Information 
elements 


P 


Condition / Comment 


OR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





MSISDN 


C 


Shall be included by the PGW if it is stored in its UE 
context 


1 


MSISDN 





Sender F-TEID for 
Control Plane 


C 


Shall be sent on S1 1 . On S5/S8 it is not needed because 
its content would be identical to the IE PGW S5/S8 
Address for Control Plane or PIVIIP 


1 


F-TEID 





PGW S5/S8 Address 
for Control Plane or 
PMIP 


M 


Shall include the TEID in the GTP based S5/S8 case and 
the GRE key in the PIVIIP based S5/S8 case 


1 


F-TEID 


1 


Protocol 

Configuration Options 
(PCO) 


C 


Used in Inter RAT handover from UTRAN or GERAN to E- 
UTRAN 


1 


PCO 





Bearer Contexts 
modified 


M 


Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers 
modified 


1 


Bearer Context 





Bearer Contexts 
marked for removal 


C 


Shall be included on S4/S1 1 in mobility cases where any of 
the bearers existing before the mobility procedure will be 
deactived as consequence of the mobility procedure. 
For each of those bearers an IE with this type and instance 
values shall be included. 


1 


Bearer Context 


1 


Recovery 


C 


Included if contacting the peer for the first time 


1 


Recovery 





Private Extension 





None 





Private Extension 


vs 



Table 7.2.8-2: Bearer Context modified within IVIodify Bearer Response 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 


1 


EBI 





Cause 


M 


Indicates if the bearer handling was successful, and if not, 
gives information on the reason. 


1 


Cause 





NSAPI 




Not used in response messages 


1 


NSAPI 


1 


S1 SGW F-TEID 


C 


Used on S11 if SI 2 is used 


1 


F-TEID 





S12SGW F-TEID 


C 


Used on S11 if SI 2 is used 


1 


F-TEID 


1 


Bearer Level QoS 




Not used in response messages 


1 


Bearer QoS 






Table 7.2.8-3: Bearer Context marked for removal withiin IVIodify Bearer Response 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 


1 


EBI 





Cause 


M 


Indicates if the bearer handling was successful, and if not, 
gives information on the reason. 


1 


Cause 






7.2.9 Delete Session Request and Delete Bearer Request 



7.2.9.1 



Delete Session Request 



A Delete Session Request message is sent on SI 1 by the MME to the SGW and on S5/S8 by the SGW to the PGW as 
part of the procedures: 

- EUTRAN Initial Attach 

- Inter MME Tracking Area Update with SGW Change 
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- UE Initiated Detach 

- HSS Initiated Detach 

- MME Initiated Detach 

- Intra MME S 1 Based Handover 

- Inter MME S 1 Based Handover without SGW Change 

- Inter MME S 1 Based Handover with SGW Change 
X2 Based handover with SGW Relocation 

UE Requested PDN Disconnection 
It is also sent on S4 by the SGSN to the SGW, and on S5/S8 by the SGW to the PGW as part of 

- MS, HLR or SGSN initiated detach procedure 

- Combined GPRS/IMSI Attach 

MS and SGSN Initiated Bearer Deactivation Procedure using S4 

and on S4 by the SGSN to the SGW as part of 

Enhanced Serving RNS Relocation without Serving GW relocation using S4Table 7.2.9.1-1 
specifies the presence of the lEs in the message. 

A Delete Session Request message may include an Indication IE, with Operation Indication (OI) bit set to 1, which is 
used to inform SGW whether the SGW should continue forwarding the message to the PGW or not when it receives this 
message. 

Table 7.2.9.1-1 : Information Elements in a Delete Session Request 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Linked EPS Bearer ID 
(LBI) 


M 


This IE shall be included to indicate the default bearer 
associated with the PDN being disconnected 


1 


EBI 





Indication Flags 


M 


Applicable flags: 

• Tear down Indicator: all bearers associated with 
the PDN connection are torn down used on 
S11/S5/S8 

• Operation Indication: always set, used on 
S11/S5/S8 

• Scope Indication: if request corresponds to S1 
based handover procedures, then this bit is set 


1 


Indication 





Protocol 

Configuration Options 
(PCO) 


C 


If the UE includes the PCO IE, then the MME shall copy 
the content of this IE transparently from the PCO IE 
included by the UE. 


1 


PCO 





Private Extension 





None 





Private Extension 


vs 



7.2.9.2 



Delete Bearer Request 



A Delete Bearer Request is shall be sent as part of PGW or MME initiated bearer deactivation procedures, execution 
part of MS initiated EPS bearer modification procedure using S4 or PGW initiated bearer deactivation procedure using 
S4.. This Request is sent by the PGW to the SGW and may be forwarded to the MME or S4-SGSN. Table 7.2.9.2-1 
specifies the presence of lEs in this message. 
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Table 7.2.9.2-1 : Information Elements in a Delete Bearer Request 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Linked EPS Bearer ID 
(LB!) 


C 


If the request corresponds to P-GW initiated detach 

procedure to deactivate all bearers belonging to a PDN 

connection, then this IE shall be included to indicate the 

default bearer associated with the PDN being 

disconnected. 

This IE shall be included only when the EPS Bearer ID List 

is not present in the message. 


1 


EBI 





Bearer Contexts 


C 


It shall be used for bearers different from the default one. 
In this case at least one bearer shall be included. 
Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 
Used for dedicated bearers. When used, at least one 
dedicated bearer shall be present 


1 


Bearer Context 





Procedure 
Transaction Id (PTI) 


c 


If the request corresponds to UE requested bearer 
resource modification procedure for an E-UTRAN or MS 
initiated EPS bearer modification procedure using S4,, this 
IE shall be included. 


1 


PTI 





APN Aggregate 
Maximum Bit Rate 
(APN-AMBR) 


c 


This IE shall be included when the P-GW initiates a delete 
procedure in case of policy updates due to the deletion of 
non GBR flows 


1 


AMBR 





Protocol 

Configuration Options 
(PCO) 


c 


The MME shall copy the content of this IE transparently 
from the PCO IE included by the UE if the PGW wishes to 
provide the UE with application specific parameters 


1 


PCO 





PGW-CSID 





Optionally included by PGW on S5/S8. Shall be forwarded 
by SGW on S1 1 . Only one value may be present per PDN 
connection 


1 


CSID 


2 


SGW-CSID 





Optionally included by SGW on S1 1 . Only one value may 
be present per PDN connection. 


1 


CSID 


1 


Private Extension 





None 





Private Extension 


vs 



Table 7.2.9.2-2: Bearer Context within Delete Bearer Request 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 




1 


EBI 






7.2.10 Delete Session Response and Delete Bearer Response 
7.2.10.1 Delete Session Response 

A Delete Session Response message shall be sent as a response to a Delete Session Request message from the SGW to 
the MME as part of the following procedures: 

- EUTRAN Initial Attach 

- Inter MME Tracking Area Update with SGW Change 

- UE Initiated Detach 

- HSS Initiated Detach 

- MME Initiated Detach 

- Intra MME S 1 Based Handover 

- Inter MME S 1 Based Handover with SGW Change 

- Inter MME S 1 Based Handover without SGW Change 



£75/ 



3GPP TS 29.274 version 8.0.0 Release 8 



38 



ETSI TS 129 274 V8.0.0 (2009-01) 



X2 Based Handover with SGW Relocation 
UE Requested PDN Disconnection 
Possible Cause values are: 

"Request accepted". 

"Request accepted". 

"Request accepted partially" 

"Request rejected" 

"Context not found" 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Missing or unknown APN". 

"User authentication failed". 

"System failure". 

"Semantic error in the TAD operation". 

"Syntactic error in the TADoperation". 

"Semantic errors in packet filter(s)". 

"Syntactic errors in packet filters(s)". 

"Optional IE incorrect". 

"Invalid message format". 

"APN access denied - no subscription". 

"All dynamic addresses are occupied" 

"Unexpected repeated IE" 

Table 7.2.10.1-1 specifies the presence of the lEs in the message. 

The sending entity shall include Cause IE in the Delete Session Response message. The IE indicates if the peer has 
deleted the bearer, or not. 

Table 7.2.10.1-1 : Information Elements in a Delete Session Response 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





Recovery 


C 


If contacting the peer for the first time 


1 


Recovery 





Protocol 

Configuration Options 
(PCO) 


C 


The IVIME shall copy the content of this IE transparently 
from the PCO IE included by the UE if the PGW wishes to 
provide the UE with application specific parameters 


1 


PCO 





Private Extension 





None 





Private Extension 


vs 



7.2.10.2 Delete Bearer Response 

The Delete Bearer Response shall be sent as a response of Delete Bearer Request. 
Possible Cause values are: 
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"Request accepted". 

"Request accepted partially" 

"Request rejected" 

"Context not found" 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Missing or unknown APN". 

"User authentication failed". 

"System failure". 

"Semantic error in the TAD operation". 

"Syntactic error in the TAD operation". 

"Semantic errors in packet filter(s)". 

"Syntactic errors in packet filters(s)". 

"Optional IE incorrect". 

"Invalid message format". 

"APN access denied - no subscription". 

"All dynamic addresses are occupied" 

"Unexpected repeated IE" 

Table 7.2.1 0.2-1: Information Elements in Delete Bearer Response 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





LBI 


C 


If tlie request corresponds to P-GW initiated detach 
procedure, this IE shall be included to deactivate all the 
bearers associated with the default bearer of a PDN 
connection. 


1 


EBI 





Bearer Contexts 


C 


It shall be used for bearers different from default one. In 
this case at least one bearer shall be included. 
Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 
Used for dedicated bearers. When used, at least one 
dedicated bearer shall be present. 


1 


Bearer Context 





Recovery 


c 


Used if contacting the peer for the first time 


1 


Recovery 





MME-CSID 





Optionally included by MME on S1 1 . Shall be forwarded by 
SOW on S5/S8. Only one value may be present per PDN 
connection 


1 


CSID 





SGW-CSID 





Optionally included by SOW on S5/S8. Only one value 
may be present per PDN connection. 


1 


CSID 


1 


Private Extension 





None 





Private Extension 


vs 
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Table 7.2.10.2-2: Bearer Context within Delete Bearer Response 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 


1 


EBI 





Cause 


M 


This IE shall indicate if the bearer handling was successful, 
and if not, gives information on the reason. 


1 


Cause 






7.2.1 1 Downlink Data Notification messages 



7.2.11.1 



Downlink Data Notification 



A Downlink Data Notification message shall be sent on S 1 1 interface by a SGW from a SGW to a MME as a part of the 
network triggered service request procedure. 

The message shall also be sent on S4 interface by a SGW from a SGW to a SGSN as part of Paging with no established 
user plane on S4, SGW triggered paging with S4. 

Table 7.2.11.1-1 specifies the presence of the lEs in the message. 

Table 7.2.11.1-1: Information Elements in a Downlink Data Notification 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 














Private Extension 





None 


1 


Private Extension 


VS 



7.2.11.2 



Downlink Data Notification Acknowledgement 



A Downlink Data Notification Acknowledgement shall be sent from a MME/SGSN to a SGW in response to Downlink 
Data Notification with an indication of success, or failure when MME/SGSN has reachability or abnormal conditions. 

Table 7.2.11.2-1 specifies the presence of the lEs in the message. 

Table 7.2.11.2-1: Information Elements in a Downlink Data Notification Acknowledgement 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





Data Notification 
Delay 


C 


The MME/SGSN shall include an adaptive delay indication 
to the SGW to delay the number of Data Notification 
indications, if the rate of Downlink Data Notification event 
occurance in the MME/SGSN becomes significant (as 
configured by the operator) and the MME/SGSN's load 
exceeds an operator configured value. 


1 


Delay Value 





Recovery 





None 


1 


Recovery 





Private Extension 





None 


1 


Private Extension 


VS 



Possible Cause values are: 
"Request accepted", 
- "Unable to page UE". 



7.2.11.3 



Downlink Data Notification Failure Indication 



A Downlink Data Notification Failure indication shall be sent from an MME/SGSN to a SGW indicating that the UE 
did not respond to paging. It shall also be sent in the case that the UE responded to the page with a Service Request but 



£75/ 



3GPP TS 29.274 version 8.0.0 Release 8 



41 



ETSI TS 129 274 V8.0.0 (2009-01) 



that the MME has rejected the request by sending a Service Reject to the UE because the requested service is not 
supported. 

Table 7.2.11.3-1 specifies the presence of the lEs in the message. 

Table 7.2.11.3-1 : Information Elements in a Downlink Data Notification Failure Indication 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





Private Extension 





None 


1 


Private Extension 


vs 



Possible Cause values are: 

"UE not responding" 
"Service denied". 
Editor's note: Other potential Cause values are FFS. 

7.2.12 Update User Plane Request 

The Update User Plane Request message is sent on S 1 1 by the MME to the SGW as part of the Inter eNodeB handover 
without MME relocation, with Serving GW relocation procedure. Table 7.2.12-1 specifies the presence of the lEs in the 

message. 

Table 7.2.12-1 : Information Elements in an Update User Plane Request 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Bearer Contexts to be 
updated 


M 


None 


1 


Bearer Context 





Bearer Contexts to be 
removed 


C 




1 


Bearer Context 


1 


Recovery 


C 


If contacting the peer for tlie first time 


1 


Recovery 





Private Extension 





None 


1 


Private Extension 


vs 



Table 7.2.12-2: Bearer Context to be updated within Update User Plane Request 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 


1 


EBI 





S1 eNodeB F-TEID 


M 


None 


1 


F-TEID 






Table 7.2.12-3: Bearer Context to be removed within Update User Plane Request 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 


1 


EBI 






7.2.13 Update User Plane Response 



The Update User Plane Response message is sent on S 1 1 by the SGW to the MME as part of the Inter eNodeB 
handover without MME relocation, with Serving GW relocation procedure. 
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Table 7.2.13-1 specifies the presence of the lEs in the message. 

Table 7.2.13-1 : Information Elements in a Update User Plane Response 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





Bearer Contexts 
updated 





None 


1 


Bearer Contexts 





Bearer Contexts 
marked for removal 





None 


1 


Bearer Contexts 


1 


Private Extension 





None 


1 


Private Extension 


vs 



Table 7.2.13-2: Bearer Context updated within Update User Plane Response 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 


1 


EBI 





Cause 


M 


Indicates if the bearer handling was successful, and if not, 
gives information on the reason. 


1 


Cause 





S1 SGW F-TEID 


C 


Used on S1 1 


1 


F-TEID 






Table 7.2.13-3: Bearer Context marked for removal within Update User Plane Response 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 


1 


EBI 





Cause 


M 


Indicates if the bearer handling was successful, and if not, 
gives information on the reason. 


1 


Cause 






7.2.14 Modify Bearer Command and Failure Indication 
7.2.14.1 Modify Bearer Command 

The Modify Bearer Command is sent on SI 1 by the MME to the SGW and on S5/S8 by the SGW to the PGW as part of 
the HSS Initiated Subscribed QoS Modification procedure. 

Table 7.2.14.1-1 : Information Elements in a Modify Bearer Command 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


APN-Aggregate 
Maximum Bit Rate 
(APN-AMBR) 


M 


This IE shall contain the modified APN-AIVIBR value 
received by the MIVIE from the HSS. 


1 


AMBR 





Bearer Contexts 


M 


Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers 


1 


Bearer Context 





Private Extension 





None 





Private Extension 


VS 
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Table 7.2.14.1-2: Bearer Context within lUlodify Bearer Command 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


This IE shall contain the bearer that has been modified. 


1 


EBI 





Bearer Level QoS 


C 


Mandatory if other parameters than the APN-AIVIBR have 
changed 


1 


Bearer QoS 






7.2.14.2 Modify Bearer Failure indication 

The Modify Bearer Failure Indication is sent on S5/S8 by the PGW to the SGW and on S 1 1 by the SGW to the MME as 
part of failure of HSS Initiated Subscribed QoS Modification procedure. 

Cause IE indicates that an EPS bearer has not been updated in the PGW. 

Possible Cause values are: 

"Context not found" 

"No resources available". 

"No memory is available". 

"Missing or unknown APN". 

"User authentication failed". 

"System failure". 

"Semantic error in the TADoperation". 

"Syntactic error in the TADoperation". 

"Semantic errors in packet filter(s)". 

"Syntactic errors in packet filters(s)". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Optional IE incorrect". 

"Invalid message format". 

"APN access denied - no subscription". 

"All dynamic addresses are occupied" 

"Unexpected repeated IE" 

Table 7.2.14.2-1 : Information Elements in a lUlodify Bearer Failure Indication 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





Bearer Context 


M 


Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers 




Bearer Context 





Recovery 


C 


Only included if contacting the peer for the first time 


1 


Recovery 





Private Extension 





None 


1 


Private Extension 


vs 
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Table 7.2.14.2-2: Bearer Context within IVIodify Bearer Failure Indication 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


This IE shall contain the bearers that have failed. 


1 


EBI 





Cause 


M 


Indicates if the bearer handling was successful, and if not, 
gives information on the reason. 


1 


Cause 






7.2.15 Update Bearer Request 



For GTP based S5/S8, the Update Bearer Request shall be sent by the P-GW to the S-GW and forwarded to the MME 
as part of the following procedures: 

- PDN GW Initiated Bearer Modification with Bearer QoS Update 

- HSS Initiated Subscribed QoS Modification 

PGW Initiated Bearer Modification without Bearer QoS Update 

UE Request Bearer Resource Modification procedure 

The message shall also be sent on S5/S8 interface by the PGW to the SGW and on S4 interface by the SGW to the 
SGSN as part of the following procedures: 

- PGW Initiated EPS Bearer Modification 

Execution part of MS-Initiated EPS Bearer Modification 

For PMIP based S5/S8, the Update Bearer Request is sent from the SGW to the MME over Sll. 

Table 7.2.15-1 specifies the presence requirements and the conditions of the lEs in the message. 

Table 7.2.15-1 : Information Elements in a Update Bearer Request 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


IMSI 


M 


None 


1 


IMSI 





Bearer Contexts 


M 


This IE shall contain contexts related to bearers that need 
QoS/TFT modification. Several lEs with this type and 
instance values shall be included as necessary to 
represent a list of Bearers. 


1 


Bearer Context 





Procedure 
Transaction Id (PTI) 


C 


If the request corresponds to UE requested bearer 
resource modification procedure for an E-UTRAN or MS 
initiated EPS bearer modification procedure, this IE shall 
be included. 

PTI shall be the same as the one used in the 
corresponding Bearer Resource Command or Modify 
Bearer Command 


1 


PTI 





Protocol 

Configuration Options 
(PCO) 


C 


PGW shall include Protocol Configuration Options (PCO) 
IE, if available. 


1 


PCO 





GRE Key 


C 


The SGW shall include the GRE Key IE for uplink traffic if 
PMIP-based S5/S8 is used 


1 


GRE Key 





Aggregate Maximum 
Bit Rate (APN-AMBR) 


M 


APN-AMBR 


1 


AMBR 





Trace Information 


C 


Trace Reference, Trace Type, Trigger Id, OMC Identitiy. 
Included if SGW and/or PGW is activated. 


1 


Trace Information 





Private Extension 





None 





Private Extension 


vs 
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Table 7.2.15-2: Bearer Context within Update Bearer Request 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 




EBI 





ULTFT 





This IE shall be included if message relates to Bearer 
Modification and TFT change or if PIVIIP based S5/S8 




Bearer TFT 





DLTFT 





PMIP based S5/S8 only 




Bearer TFT 


1 


Bearer Level QoS 


C 


This IE shall be included if QoS modification is requested 
and no TFT change 




Bearer QoS 





Legacy QoS 


C 


This IE shall be included if QoS modification is requested 
and no TFT change 




Legacy QoS 





Charging 
Characteristics 


C 


To be included according to TS 32.251 . To be included 
according to TS 32.251 




Charging 
Characteristics 





Charging Id 


C 


None 




Charging Id 





Prohibit Payload 
Compression 





None 




Prohibit Payload 
Compression 






7.2.16 Update Bearer Response 



An Update Bearer Response shall be sent from a MME/SGSN to a SGW and forwarded to the PGW as a response to an 
Update Bearer Request message. 

Table 7.2.16-1 specifies the presence requirements and the conditions of the lEs in the message. 

Cause IE indicates if an EPS bearer has been modifed in the MME/SGSN or not. The EPS Bearer has not been modified 
in the MME if the Cause IE value differs from "Request accepted" or "Request accepted partially". Possible Cause 
values are: 

"Request accepted". 

"Request accepted partially" 

"Request accepted partially" 

"Request rejected" 

"Context not found" 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Missing or unknown APN". 

"User authentication failed". 

"System failure". 

"Semantic error in the TFT operation". 

"Syntactic error in the TFT operation". 

"Semantic errors in packet filter(s)". 

"Syntactic errors in packet filters(s)". 

"Optional IE incorrect". 

"Invalid message format". 

"APN access denied - no subscription". 

"All dynamic addresses are occupied" 
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"Unexpected repeated IE" 



Table 7.2.16-1 : Information Elements in an Update Bearer Response 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





Bearer Contexts 


M 


This IE shall contain contexts related to bearers for which 
QoS/TFT modification was requested. Several lEs with this 
type and instance values shall be included as necessary to 
represent a list of Bearers 


1 


Bearer Context 





Protocol 

Configuration Options 
(PCO) 


C 


IVIME/SGSN shall include PCO IE if such information was 
received from the PGW. This IE shall be included if the 
Cause IE contains the value "Request accepted". 


1 


PCO 





Recovery 


C 


If contacting the peer for the first time 


1 


Recovery 





Private Extension 





None 


1 


Private Extension 


vs 



Table 7.2.16-2: Bearer Context within Update Bearer Response 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 


1 


EBI 





Cause 


M 


Indicates if the bearer handling was successful, and if not, 
gives information on the reason. 


1 


Cause 






7.2.17 Delete Bearer Command and Failure Indication 



7.2.17.1 



Delete Bearer Command 



A Delete Bearer Command message shall be sent from a MME to a SGW on SI 1 and forwarded to PGW on S5/S8 as a 
part of the eNodeB requested bearer modification or MME-Initiated Dedicated Bearer Deactivation procedure. 

Table 7.2.17.1-1 : Information Elements in Deactivate Bearer Command 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Bearer Contexts 


M 


This IE shall be used to indicate dedicated bearers. When 
used, at least one dedicated bearer shall be present. 
Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers 


1 


Bearer Context 





Private Extension 





None 





Private Extension 


VS 



Table 7.2.17.1-2: Bearer Context within Deactivate Bearer Command 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 


1 


EBI 






7.2.17.2 



Delete Bearer Failure Indication 



A Delete Bearer Failure Indication is sent on S5/S8 by the PGW to the SGW and on SI 1 by the SGW to the MME as 
part of failure of MME Initiated Dedicated Bearer Deactivation procedure. 

Cause IE indicates that an EPS bearer has not been deleted in the PGW. 
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Possible Cause values are: 
"Context not found" 
"Mandatory IE incorrect". 
"Mandatory IE missing". 
"Missing or unknown APN". 
"User authentication failed". 
"System failure". 

"Semantic error in the TAD operation". 
"Syntactic error in the TAD operation". 
"Semantic errors in packet filter(s)". 
"Syntactic errors in packet filters(s)". 
"Optional IE incorrect". 
"Invalid message format". 
"APN access denied - no subscription". 
"All dynamic addresses are occupied" 
"Unexpected repeated IE" 
Editor's Note: Additional cause values are FFS. 

Table 7.2.17.2-1 : Information Elements in a Deactivate Bearer Failure Indication 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





Bearer Context 


M 


This IE shall contain the list of failed bearers. 


1 


Bearer Context 





Recovery 


C 


Used If contacting the peer for the first time 


1 


Recovery 





Private Extension 





None 


1 


Private Extension 


vs 



Table 7.2.17.2-2: Bearer Context within Deactivate Bearer Failure Indication 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 


1 


EBI 





Cause 


M 


This IE shall indicate if the bearer handling was successful, 
and if not, gives information on the reason. 


1 


Cause 






7.2.18 Create Indirect Data Forwarding Tunnel Request 

The Create Indirect Data Forwarding Tunnel Request message is sent on S11/S4 by the MME/SGSN to the SGW as 
part of the Handover procedures. 

Table 7.2.18-1 specifies the presence requirements and the conditions of the lEs in the message. 
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Table 7.2.18-1 : Information Elements in a Create Indirect Data Forwarding Tunnel Request 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Bearer Contexts 


M 


Several IBs with this type and instance values shall be 
included as necessary to represent a list of Bearers 


1 


Bearer Context 





Private Extension 





None 





Private Extension 


vs 



Table 7.2.18-2: Bearer Context within Create Indirect Data Forwarding Tunnel Request 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 


1 


EBI 





S1 eNodeB F-TEID 


C 


Target eNodeB F-TEID. 

This IE shall be present in the message sent from the 

target IVIME to the target SGW 


1 


F-TEID 





S1-USGWF-TEID 


C 


Target SOW F-TEID 

This IE shall be present in the message sent from the 

source IVIME to the source SGW 


1 


F-TEID 


1 


S4-U SGSN F-TEID 


C 


Target SGSN F-TEID 

This IE shall be present in the message sent from the 

target SGSN to the target SGW when direct tunnel is not 

used 


1 


F-TEID 


2 


S12RNC F-TEID 


C 


Target RNC F-TEID 

This IE shall be present in the message sent from the 

target SGSN to the target SGW when direct tunnel is used 


1 


F-TEID 


3 



7.2.19 Create Indirect Data Forwarding Tunnel Response 

A Create Indirect Data Forwarding Tunnel Response message shall be sent by a Serving GW to an MME/SGSN as a 
response to a Create Indirect Data Forwarding Tunnel Request message. 

Table 7.2.19-1 specifies the presence requirements and the conditions of the IBs in the message. 

The Cause value indicates if the Indirect Data Forwarding Tunnels has been created in the Serving GW or not. Indirect 
Data Forwarding Tunnels have not been created in the Serving GW if the Cause differs from 'Request accepted'. 
Possible Cause values are: 

"Request Accepted". 

"No resources available". 

"System failure". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Optional IE incorrect". 

"Invalid message format". 

Only the Cause IE shall be included in the response if the Cause IE contains another value than 'Request accepted'. 
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Table 7.2.19-1 : Information Elements in a Create Indirect Data Forwarding Tunnel Response 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





Bearer Contexts 


M 


Several IBs with this type and instance values shall be 
included as necessary to represent a list of Bearers 


1 


Bearer Context 





Private Extension 





None 





Private Extension 


vs 



Table 7.2.19-2: Bearer Context within Create Indirect Data Forwarding Tunnel Response 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 


1 


EBI 





Cause 


M 


Indicates if the tunnel setup was successful, and if not, 
gives information on the reason. 


1 


Cause 





S1-USGWF-TEID 


C 


It is the target SGW F-TEID when present in the response 

sent from the target SGW to the target MME. 

Or 

It is the source SGW F-TEID when present in the response 

sent from the source SGW to the source MME. 


1 


F-TEID 





S12SGWF-TEID 


C 


S12 usage only. 

It is the target SGW F-TEID when present in the response 

sent from the target SGW to the target SGSN. 

Or 

It is the source SGW F-TEID when present in the response 

sent from the source SGW to the source SGSN. 


1 


F-TEID 


1 


S4-U SGW F-TEID 


C 


S4-U usage only. 

It is the target SGW F-TEID when present in the response 

sent from the target SGW to the target SGSN. 

Or 

It is the source SGW F-TEID when present in the response 

sent from the source SGW to the source SGSN. 


1 


F-TEID 


2 



7.2.20 Update Bearer Complete 



The Update Bearer Complete message is sent on S4 by the SGW to the SGSN as part of the MS or SGSN initiated 
modification procedure. 

Table 7.2.20-1 specifies the presence of the lEs in the message. 

Table 7.2.20-1 : Information Elements in an Update Bearer Complete 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





Bearer Contexts 


M 


Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers 


1 


Bearer Context 





Private Extension 





None 


1 


Private Extension 


VS 



Table 7.2.20-2: Bearer Context within Update Bearer Complete 



Bearer Context IE Type = 96 (decimal) 


Length = n (decimal) 


Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


M 


None 


1 


EBI 





Cause 


M 


Indicates if the bearer handling was successful, and if not, 
gives information on the reason. 


1 


Cause 
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7.3 Mobility IVIanagement IVIessages 
7.3.1 Forward Relocation Request 

A Forward Relocation Request message shall be sent from the source MME to the target MME over SIO interface as 
part of SI -based handover relocation procedure from the source MME to the target SGSN, or from the source SGSN to 
the target MME over S3 interface as part of Inter RAT handover and combined hard handover and SRNS relocation 
procedures, or from source SGSN to the target SGSN over S16 interface as part of SRNS Relocation and PS handover 
procedures. 

Table 7.3.1-1 specifies the presence requirements and conditions of the lEs in the message. 
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Table 7.3.1-1: Information Elements in a Forward Relocation Request 



Information 
elements 


P 


Condition / Comment 


OR 


IE Type 


Ins. 


IMSI 


M 


None 


1 


IMSI 





Sender's F-TEIDfor 
Control Plane 


M 


This IE specifies the address and the tunnel for control 
plane message which is chosen by the source 
MME/SGSN. 


1 


F-TEID 





MME/SGSN UE EPS 
Bearer Contexts 


M 


Several lEs with this type and instance values shall be 
included as necessary to represent a list of PDN 
Connections 


1 


PDN Connection 





MME/SGSN UE MM 
Context 


M 


None 


1 


MM Context 





Indication 


C 


This IE shall be included if either one of the DPI flag and 

ISRSI flag is set. 

DPI flag is set if direct fonwarding is supported. DPI flag 

shall not be set if the message is used for SRNS relocation 

procedure. 

ISRSI flag is set if the source MME/SGSN is capable to 

establish ISR for the UE or if the ISR is activated, the 

source MME/SGSN then indicate the target SGSN/MME to 

maintain ISR for the UE in the inter RAT handover 

procedures. 


1 


Indication 





E-UTRAN 

Transparent 

Container 


C 


This IE shall be included if the message is used for 
UTRAN/GERAN to E-UTRAN inter RAT handover 
procedure, intra RAT handover procedure and 3G SGSN 
to MME combined hard handover and SRNS relocation 
procedure. 


1 


F-Container 





UTRAN Transparent 
Container 


c 


This IE shall be included if the message is used for PS 
handover to UTRAN lu mode procedures, SRNS relocation 
procedure and E-TURAN to UTRAN inter RAT handover 
procedure. 


1 


F-Container 


1 


Target Identification 


c 


This IE shall be included if the message is used for SRNS 
relocation procedure and handover to UTRAN/E-UTRAN 
procedures. 


1 


Target 
Identification 





HRPD access node 
S101 IP address 


c 


This IE shall be included only if the HRPD pre registration 
was performed at the source MME 


1 


S1 01 -IP-Address 





1XIWSS102IP 
address 


c 


This IE shall be included only if the 1xRTT CS fallback pre 
registration was performed at the source MME 


1 


S102-IP-Address 





RAN Cause 


c 


This IE is the information from the source eNodeB, the 
source MME shall include this IE in the message. 


1 


F-Cause 





RANAP Cause 


c 


This IE is the information from the source RNC, the source 
SGSN shall include this IE in the message. 


1 


F-Cause 


1 


BSS Container 


c 


This IE shall be included if the message is used for PS 
handover to GERAN A/Gb mode and E-UTRAN to GERAN 
A/Gb mode inter RAT handover procedure. 


1 


F-Container 





Cell Identification 


c 


This IE shall be included if the message is used for PS 
handover to GERAN A/Gb mode and E-UTRAN to GERAN 
A/Gb mode inter RAT handover procedure. 


1 


Cell Identification 





BSSGP Cause 


c 


This IE is the information from source BSS, the source 
SGSN shall include this IE in the message. 


1 


F-Cause 


2 


Selected PLMN ID 





The Selected PLMN ID IE indicates the core network 
operator selected for the UE in a shared network. The old 
SGSN shall include this IE if the selected PLMN identity is 
available. 


1 


Selected PLMN 
ID 





EPS Bearer Contexts 
Prioritization 





When the EPS Bearer Context Prioritization IE is included, 
it informs the target MME/SGSN that the EPS bearer 
Contexts are sent prioritized. 


1 


Contexts 
Prioritization 





Recovery 


c 


If contacting the peer for the first time 


1 


Recovery 





Private Extension 





None 


1 


Private Extension 


vs 



7.3.2 Forward Relocation Response 

A Forward Relocation Response message shall be sent as a response to Forward Relocation Request during SI -based 
handover procedure, Inter RAT handover procedures, SRNS Relocation procedure and PS handover procedures. 
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Table 7.3.2-1 specifies the presence requirements and conditions of the lEs in the message. 

Cause IE indicates if the relocation has been accepted, or not. The relocation has not been accepted by the target 
MME/SGSN if the Cause IE value differs from "Request accepted". Possible Cause values are: 

"Request accepted". 

'System failure'. 

'Mandatory IE incorrect'. 

'Mandatory IE missing'. 

'Optional IE incorrect'. 

'No resources available'. 

'Invalid message format'. 

'Relocation failure'. 
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Table 7.3.2-1 : Information Elements in a Forward Relocation Response 



Information 
elements 


P 


Condition / Comment 


OR 


IE Type 


Ins. 


Cause 


M 




1 


Cause 





Sender's F-TEIDfor 
Control Plane 


C 


If the Cause IE contains the value"" Request accepted"", 
the target I\/1ME/SGSN shall include this IE in Forward 
Relocation Response message. 


1 


F-TEID 





Indication 


C 


This IE shall be included if the target IVIME/SGSN has 
selected a new SOW. This IE shall not be included if the 
message is used for SRNS relocation procedure. 
SGWCI flag is set to indicate Serving GW change. 


1 


Indication 





List of Set-up Bearers 


c 


The list of set-up Bearers IE contains the EPS bearer 
Identifiers of the Bearers that were successfully allocated 
in the target system during a handover procedure. This IE 
shall be included if the Cause IE contains the value 
"Request accepted". 

Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 


1 


Bearer Context 





List of Set-up RABs 


c 


The list of set-up RABs IE contains the RAB Identifiers of 
the RABs that were successfully allocated in the target 
system. This IE shall be included if the Cause IE contains 
the value "Request accepted". 
Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 


1 


Bearer Context 


1 


eNodeB Cause 


c 


If the Cause IE contains the value "Request accepted", this 
IE is mandatory if cause value is contained in S1-AP 
message. 


1 


F-Cause 





RANAP Cause 


c 


If the Cause IE contains the value "Request accepted", this 
IE is mandatory if cause value is contained in RANAP 
message. 


1 


F-Cause 


1 


E-UTRAN 

Transparent 

Container 





This IE contains the radio-related and core network 
information for handover to E-UTRAN. If the Cause IE 
contains the value "Request accepted", this IE is included. 


1 


F-Container 





UTRAN Transparent 
Container 





This IE contains the radio-related and core network 
information for handover to UTRAN. If the Cause IE 
contains the value "Request accepted", this IE is included. 


1 


F-Container 


1 


BSS Container 





This IE contains the radio-related and core network 
information for handover to GERAN. If the Cause IE 
contains the value "Request accepted", this IE is included. 


1 


F-Container 


2 


List of Set-up PFCs 





The list of set-up PFCs IE contains the Packet Flow 
Identifies of the PFCs that were successfully allocated in 
the target system during a PS handover to/from GERAN or 
inter RAT handover to/from GERAN. If the Cause IE 
contains the value "Request accepted", this IE is included. 


1 


Bearer Context 
List 





BSSGP Cause 





For handover to GERAN, if a cause value is received from 
the Target BSC, the BSSGP Cause IE shall be included 
and shall be sent to the cause value received from the 
target BSC. 


1 


F-Cause 


2 


Private Extension 





None 


1 


Private Extension 


VS 



Bearer Context IE in this message is specified in Table 7.3.2-2, the source system shall use this IE for data forwarding 
in handover. 
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Table 7.3.2-2: Bearer Context 







Bearer Context IE Type = 96 (decimal) 












Length = n (decimal) 








Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


EPS Bearer ID 


C 


This IE shall be included if the message is used for S1- 
Based handover procedure. 




EBI 





NSAPI 


C 


This IE shall be included if the message is used for SRNS 
relocation procedure and Inter RAT handover to/from lu 
mode procedures. 




NSAPI 





Packet Flow ID 


c 


This IE shall be included if the message is used for PS 
handover and Inter RAT handover to/from A/Gb mode 
procedures. 




Packet Flow ID 





eNBF-TEID for data 
forwarding 


c 


This eNB F-TEID shall be included for direct data 
forwarding. 




F-TEID 





SGW F-TEID for data 
forwarding 


c 


This SGW F-TEID shall be included for indirect data 
forwarding. 




F-TEID 


1 



7.3.3 Forward Relocation Complete Notification 

A Forward Relocation Complete Notification message shall be sent to the source MME/SGSN to indicate the handover 
has been successfully finished. 

Table 7.3.3-1 specifies the presence requirements and conditions of the IBs in the message. 

Table 7.3.3-1 : Information Elements in a Forward Relocation Complete Notification 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Indication 


C 


This IE shall be included if the message is used for inter 

RAT handover, and the UE has ISR capability. Available 

flags: 

ISRAI flag is set to indicate to the source MME/SGSN 

whether it shall maintain the UE's context and whether it 

shall activate ISR. 


1 


Indication 





Private Extension 





None 


1 


Private Extension 


vs 



7.3.4 Forward Relocation Complete Acknowledge 

A Forward Relocation Complete Acknowledge message shall be sent as a response to Forward Relocation Complete 
Notification during inter eNodeB handover with MME relocation procedure. 

Table 7.3.4-1 specifies the presence requirements and conditions of the IBs in the message. 

Table 7.3.4-1 : Information Elements in a Forward Relocation Complete Acknowledge 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





Recovery 





None 


1 


Recovery 





Private Extension 





None 


1 


Private Extension 


VS 















7.3.5 Context Request 



The new MMB/SGSN shall send the Context Request message to the old MMB/SGSN on S3/S16/S10 interface as a 
part of TAU/RAU procedure to get the MM and BPS bearer Contexts for the UB. 
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If the sending node is a MME, it shall include in the Context Request message: 

the GUTI IE and Complete TAU Request Message IE if the GUTI received from UE indicates the old node is a 
MME. 

- the RAI IE, P-TMSI IE and P-TMSI Signature IE if the GUTI received from UE indicates the old node is an 
SGSN. 

Editor's note: It is FFS if other means than GUTI could be needed to identify the old nodes. 

If the sending node is an SGSN, it shall include RAI IE, P-TMSI IE and P-TMSI Signature IE in the Context Request 

message. 

The new MME differentiates the type of the old node from the most significant bit of the MME group id in GUTI. The 
value indicates that the old node is an SGSN, the GUTI shall be mapped to RAI and P-TMSI by the new MME; and 
the value 1 indicates the old node is a MME, the new MME include GUTI IE and Complete TAU Request Message IE 
in the Context Request message. The Mapping between temporary and area identities is defined in 3GPP TS 23.003 [2]. 

The GUTI IE shall not coexist with any of the RAI IE, P-TMSI IE and P-TMSI Signature IE in a Context Request 
message. If this occurs, the receiving node shall return a corresponding cause value in the response message. 



Table 7.3.5-1 specifies the presence requirements and conditions of the lEs in the message. 
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Table 7.3.5-1 : Information Elements in a Context Request 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


IMSI 


C 


IIVISI shall be included if the l\/IS Validated value indicates 
'YES'. 


1 


IMSI 





GUTI 


C 


The New IVIME shall include this IE over S10 interface. 


1 


GUTI 





Routeing Area 
Identity(RAI) 


c 


This IE shall be included over S3/S16 interface, if the GUTI 
indicates the old node is an SGSN, the new IVIME maps 
this IE from GUTI. 


1 


ULI for RAI 





Packet TMSI(P-TMSI) 


c 


This IE shall be included over S3/S16 interface, if the GUTI 
indicates the old node is an SGSN, the new MME maps 
this IE from GUTI. 


1 


P-TMSI 





P-TMSI Signature 


c 


This IE shall be included over S3/S16 interface, if the GUTI 
indicates the old node is an SGSN, the new IVIIVIE maps 
this IE from GUTI. 


1 


P-TMSI Signature 





Complete TAU 
request message 


c 


The new MME shall include this IE, and the old MME may 
use this IE for integrity checl<. 


1 


Complete 
Request Message 





S3/S16/S10 Address 
and TEID for Control 
Plane 


c 


This IE specifies the address and the tunnel for control 
plane message which is chosen by the new MME/SGSN. 


1 


F-TEID 





UDP Source Port 
Number 


c 


If an SGSN within the same SGSN pool as the old SGSN 
receives this message, the SGSN shall include the UDP 
Source Port number of the received message in this 
optional parameter if this IE is not present and relay the 
message to the old SGSN. The old SGSN shall use this 
UDP port as the UDP destination port of the Context 
Response message. 


1 


Port Number 





RAT Type 


c 


The RAT Type indicates the Radio Access Technology 
which is used in the new system. 


1 


RAT Type 





HRPD access node 
S101 IP address 


c 


This IE shall be included only if the HRPD pre registration 
was performed at the old MME 


1 


S1 01 -IP-Address 





1XIWSS102IP 
address 


c 


This IE shall be included only if the 1xRTT CS fallback pre 
registration was performed at the old MME 


1 


S102-IP-Address 





MS Validated 





The MS Validated indicates that the new system has 
successfully authenticated the UE, IMSI shall be included if 
the MS Validated value indicates 'YES'. 


1 


MS Validated 





Hop Counter 





If an SGSN within the same SGSN pool with the old SGSN 
receives this message, the SGSN shall decrement the Hop 
Counter if this IE is present in the received message; 
otherwise may include a Hop Counter with a value of max- 
1 , and relay the message to the old SGSN. 


1 


Hop Counter 





Private Extension 





None 


1 


Private Extension 


vs 



Editor's note: It is FFS whether there is more Information Element for this message. 

7.3.6 Context Response 

A Context Response message shall be sent as a response to a previous Context Request message during TAU/RAU 
procedure. 

Possible Cause values are: 

- 'Request Accepted'. 

- 'IMSI not known'. 

- 'System failure'. 
'Mandatory IE incorrect'. 
'Mandatory IE missing'. 
'Optional IE incorrect'. 

- 'Invalid message format'. 
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'P-TMSI Signature mismatch'. 
Editor's note: Other potential Cause values are FFS. 
Table 7.3.6-1 specifies the presence requirements and conditions of the lEs in the message. 

Table 7.3.6-1 : Information Elements in a Context Response 



Information 
elements 


P 


Condition / Comment 


OR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





IMSI 


C 


None 


1 


IMSI 





MME/SGSN UE MM 
Context 


C 


None 


1 


MM Context 





MME/SGSN UE ESP 
bearer Contexts 


c 


Tliis IE shall be included if tfiere is at least a PDN 
connection for this UE on the sending MME/SGSN. 
Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 


1 


PDN Connection 





S3/S16/S10 Address 
and TEID for Control 
Plane 


c 


This IE specifies the address and the tunnel for control 
plane message which is chosen by the old MME/SGSN. 


1 


F-TEID 





ISRSI 


c 


This IE shall be included if the Cause IE value indicates 
"Request accepted" and the old system has the ISR 
capability. 


1 


Indication 





EPS Bearer Contexts 
Prioritization 





When the EPS Bearer Context Prioritization IE is included, 
it informs the new MME/SGSN that the EPS bearer 
Contexts are sent prioritized. 


1 


Contexts 
Prioritization 





Private Extension 





None 


1 


Private Extension 


vs 



Editor's note: It is FFS whether there is more Information Element for this message. 



7.3.7 Context Acknowledge 



A Context Acknowledge message shall be sent as a response to a previous Context Response message. 
Possible cause values are: 

'Request accepted'. 

'System failure'. 

'Mandatory IE incorrect'. 

'Mandatory IE missing'. 

'Optional IE incorrect'. 

'No resources available'. 

'Invalid message format'. 

'Authentication failure'. 
Editor's note: Other potential Cause values are FFS. 
Table 7.3.7-1 specifies the presence requirements and conditions of the lEs in the message. 
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Table 7.3.7-1 : Information Elements in a Context Acknowledge 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





SGW Change 
Indication 


C 


SGW ctiange indication indicates a new Serving GW has 
been selected. The old MME/old SGSN marks in its 
context that the information in the GWs and the HSS are 
invalid. 


1 


Indication 





ISRAI 


C 


ISR indicates to the old system that it shall maintain the 
UE's contexts. This IE shall be included if the Cause IE 
value indicates "Request accepted". 


1 


Indication 


1 


Private Extension 





None 


1 


Private Extension 


vs 



Editor's note: It is FFS whether there is more Information Element for this message. 

7.3.8 Identification Request 

If the UE identifies itself with temporary identity and it has changed SGSN/MME since detach in Attach procedure, the 
new MME/SGSN shall send an Identification Request message to the old SGSN/MME over S3, S16 or SIO interface to 
request IMSI. 

Table 7.3.8-1 specifies the presence requirements and conditions of the lEs in the message. 

If the sending node is a MME, it shall include in the Identification Request message: 

• the GUTI IE and Complete Attach Request Message IE if the GUTI received from UE indicates the old 
node is a MME. 

• the RAI IE, P-TMSI IE and P-TMSI Signature IE if the GUTI received from UE indicates the old node is 
an SGSN. 

Editor's note: It is FFS if other means than GUTI could be needed to identify the old nodes. 

If the sending node is an SGSN, it shall include RAI IE, P-TMSI IE and P-TMSI Signature IE in the Identification 
Request message. 

The new MME differentiates the type of the old node from the most significant bit of the MME group id in GUTI. The 
value indicates that the old node is an SGSN, the GUTI shall be mapped to RAI and P-TMSI by the new MME; and 
the value 1 indicates the old node is a MME, the new MME include GUTI IE and Complete Attach Request Message IE 
in the Identification Request message. The Mapping between temporary and area identities is defined in 3GPP TS 
23.003 [2]. 

The GUTI IE shall not coexist with any of the RAI IE, P-TMSI IE and P-TMSI Signature IE in an Identification 
Request message. If this occurs, the receiving node shall return a corresponding cause value in the response message. 
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Table 7.3.8-1 : Information Elements in an Identification Request 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


GUTI 


C 


The new MME shall include this IE over S10 interface. 


1 


GUTI 





Routeing Area 
Identity(RAI) 


C 


This IE shall be included over S3/S16 interface, if the GUTI 
received from the UE indicates the old node is an SGSN, 
the new MME maps this IE from GUTI. 


1 


ULI for RAI 





Packet TMSI(P-TMSI) 


c 


This IE shall be included over S3/S16 interface, if the GUTI 
received from the UE indicates the old node is an SGSN, 
the new MME maps this IE from GUTI. 


1 


P-TMSI 





P-TMSI Signature 


c 


This IE shall be included over S3/S16 interface, if the GUTI 
received from the UE indicates the old node is an SGSN, 
the new MME maps this IE from GUTI. 


1 


P-TMSI Signature 





Complete Attach 
Request Message 


c 


The new MME shall include this IE over S10 interface, and 
the old MME may use this IE for integrity check. 


1 


Complete 
Request Message 





Address for Control 
Plane 





If an SGSN within the same SGSN pool with the old SGSN 
receives this message, the SGSN shall include the old IP 
address of the received message in this optional 
parameter if this IE is not present and relay the message to 
the old SGSN. 


1 


IP Address 





UDP Source Port 
Number 


c 


If an SGSN within the same SGSN pool as the old SGSN 
receives this message, the SGSN shall include the UDP 
Source Port number of the received message in this 
optional parameter if this IE is not present and relay the 
message to the old SGSN. The old SGSN shall use this 
UDP port as the UDP destination port of the Identification 
Response message. 


1 


Port Number 





Hop Counter 





If an SGSN within the same SGSN pool with the old SGSN 
receives this message, the SGSN shall decrement the Hop 
Counter if this IE is present in the received message; 
otherwise may include a Hop Counter with a value of max- 
1 , and relay the message to the old SGSN. 


1 


Hop Counter 





Private Extension 





None 


1 


Private Extension 


vs 



Editor's note: It is FFS whether there is more Information Element for this message. 

7.3.9 Identification Response 

The old SGSN/MME shall send an Identification Response message to the new MME/SGSN as a response to a previous 
Identification Request message over S3/S10/S16 interface. 

Table 7.3.9-1 specifies the presence requirements and conditions of the lEs in the message. 

For Intra Domain Connection of RAN Nodes to Multiple CN Nodes, if an old SGSN within an SGSN pool receives an 
Identification Request message that contains the optional parameter Address for Control Plane, the old SGSN shall use 
this address as destination IP address of the Identification Response message. 

Possible Cause values are: 

'Request accepted' . 

'IMSI not known'. 

'System failure'. 

'Mandatory IE incorrect' . 

'Mandatory IE missing'. 

'Optional IE incorrect' . 

'Invalid Message format' 

'P-TMSI Signature mismatch' . 



ETSI 



3GPP TS 29.274 version 8.0.0 Release 8 



60 



ETSI TS 129 274 V8.0.0 (2009-01) 



Editor's note: Other potential Cause values are FFS. 

Only the Cause information element shall be included in the response if the Cause contains another value than 'Request 
accepted' . 

One or several Authentication Quadruplet information elements. Authentication Quintuplet information elements may 
be included in the message if the Cause contains the value 'Request accepted'. 

Table 7.3.9-1 : Information Elements in an Identification Response 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





IMSI 


C 


This IE is mandatory if the Cause contains the value 
'Request accepted'. 


1 


IMSI 





Authentication 
Quadruplet 





If the Cause contains the value 'Request accepted', the old 
node may include one or several Authentication 
Quadruplet in the Identification Response message. 


1 


Authentication 
Quadruplet 





Authentication 
Quintuplet 





If the Cause contains the value 'Request accepted', the old 
node may include one or several Authentication Quintuplet 
in the Identification Response message. 


1 


Authentication 
Quintuplet 


1 


Private Extension 





None 


1 


Private Extension 


vs 



Editor's note: It is FFS whether there is more Information Element for this message. 

7.3.10 Forward SRNS Context Notification 

A Forward SRNS Context Notification message shall be sent from the Old SGSN to the New SGSN over S16 interface 
to forward the RNC contexts to the target system. 

When the old SGSN receives the RANAP message Forward SRNS Context, the old SGSN shall send a Forward SRNS 
Context Notification message to the new SGSN. The new SGSN shall forward the message to the target RNC using the 
corresponding RANAP message. 

When the old SGSN receives a BSSGP message PS handover Required and the acknowledged peer-to-peer LLC 
operation is used for the Bearer Context or when "delivery order" is set in the Bearer Context QoS profile, the old 
SGSN shall send a Forward SRNS Context Notification message with the PDU Number IE to the new SGSN. The new 
SGSN shall forward the message to the target RNC/ target BSS using the corresponding RANAP message only for PS 
handover to lu mode. 

When the old SGSN receives a BSSGP message PS handover Required from source BSS/RNC for PS handover to 
A/Gb mode, the value part of RAB Context IE shall be empty according to its defined minimum length. 

Table 7.3.10-1 specifics the presence requirements and conditions of the lEs in the message. 

Table 7.3.10-1 : Information Elements in a Forward SRNS Context Notification 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


RAB Contexts 


M 


Several lEs with this type and instance values shall be 
included as necessary to represent a list of Bearers. 
For each RAB context in the received RANAP message, 
the old SGSN shall include this IE in the message. 


1 


RAB Context 





Source RNC PDCP 
context Info 





If available, the old SGSN shall include an Source RNC 
PDCP context info in the message. 


1 


Source RNC 

PDCP context 

Info 





PDU Numbers 





The old SGSN shall include this IE in the message if the 
acknowledged peer-to-peer LLC operation is used for the 
Bearer Context or when "delivery order" is set in the 
Bearer Context QoS profile in A/Gb mode to lu/A/Gb mode 
PS handover. 


1 


PDU Numbers 





Private Extension 





None 


1 


Private Extension 


VS 
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Editor's note: It is FFS whether there is more Information Element for this message. 

7.3.1 1 Forward SRNS Context Acknowledge 

A Forward SRNS Context Acknowledge message shall be sent to the old SGSN as a response to Forward SRNS 
Context Notification. 

Possible Cause values are: 

'Request Accepted'. 

'Mandatory IE incorrect'. 

'Mandatory IE missing'. 

'Optional IE incorrect'. 

- 'Invahd message format'. 

Editor's note: Other potential Cause values are FFS. 

Table 7.3.1 1-1 specifics the presence requirements and conditions of the lEs in the message. 

Table 7.3.11-1 : Information Elements in a Forward SRNS Context Acknowledge 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





Private Extension 





None 


1 


Private Extension 


vs 



Editor's note: It is FFS whether there is more Information Element for this message. 

7.3.12 Detach Notification 

A Detach Notification message shall be sent from an MME to the associated SGSN, or from an SGSN to the associated 
MME as a part of Detach procedure if the ISR is activated between the MME and SGSN for the UE. 

Possible Cause values are: 

"Local Detach". 

"Complete Detach". 

'Local Detach' indicates that this detach is local to the MME/SGSN and so the associated SGSN/MME registi-ation 
where the ISR is activated shall not be detached. The MME/SGSN that receives this message including this Cause value 
of 'Local Detach' only deactivates the ISR. This Cause value shall be included in the procedures: 

MME/SGSN-initiated Detach Procedure in case of implicit detach. 

HSS-initiated Detach Procedure. 

'Complete Detach' indicates both the MME registration and the SGSN registration that the ISR is activated for, shall be 
detached. This 'Complete Detach' Cause value shall be included in the procedures: 

UE-initiated Detach Procedure. 

MME/SGSN-initiated Detach Procedure in case of explicit detach. 

Table 7.3.12-1 specifics the presence of the lEs in the message. 
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Table 7.3.12-1 : Information Elements in a Detach Notification 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


IMSI 


M 


None 


1 


IMSI 





Cause 


M 


None 


1 


Cause 





Private Extension 





None 





Private Extension 


vs 



Editor's notes; It is FFS whether there is more Information Element for this message. 

7.3.13 Detach Acknowledge 

A Detach Acknowledge message shall be sent as a response to a Detach Notification message during Detach procedure. 
Possible Cause values are: 

'Request accepted' . 

'IMSI not known'. 

'System failure' . 

'Mandatory IE incorrect'. 

'Mandatory IE missing'. 

'Optional IE incorrect' . 

'Invalid Message format' 
Editor's note: Other potential Cause values are FFS. 
Table 7.3.13-1 specifics the presence of the lEs in the message. 

Table 7.3.13-1 : Information Elements in a Detach Acknowledge 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





Recovery 





None 


1 


Recovery 





Private Extension 





None 





Private Extension 


vs 



Editor's notes: It is FFS whether there is more Information Element for this message. 

7.3.14 Change Notification Request 

The Change Notification Request message is sent on the S4 interface by the SGSN to the SGW and on the S5/S8 
interface by the SGW to the PGW as part of location dependent charging related procedures. 

The TEID value used in this message shall be zero. 
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Table 7.3.14-1 : Information Element in Change Notification Request 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


IMSI 


M 


None 


1 


IMSI 





RAT Type 


M 


None 


1 


RAT Type 





User Location 
Information (ULI) 


C 


The SGSN shall include the User Location Information IE if 
the IVIS is located in a RAT Type of GERAN, UTRAN or 
GAN and shall include the CGI, SAI or RAI in the 
'Geographic Location' field depending on whether the IVIS 
is in a cell, a service or a routing area respectively. 


1 


ULI 





Private Extension 





Vendor or operator specific information 





Private Extension 


vs 



7.3.15 Change Notification Response 



The Change Notification Request message is sent on the S4 interface by the SGW to the SGSN and on the S5/S8 
interface by the PGW to the SGW as part of location dependent charging related procedures to acknowledge the receipt 
of a Change Notification Request. 

The TEID value used in this message shall be zero. 

If the IMSI is unknown for the receiving GTP-C entity, then the message shall be silently discarded and no further 
processing of the lEs shall continue. 

Editor's Note: It is FFS if GGSN shall be replaced by PGW in the following text. 

If the received Change Notification Response contains a Cause value of 'IMSI not known', then the Change Reporting 
mechanism shall be stopped in the receiving SGSN for all PDP Contexts or Bearers associated with the IMSI received 
and the GGSN from which the response was received. The SGSN shall then initiate an Update PDP Context for all of 
these PDP Contexts associated with the GGSN. 

If the MS Info Change Reporting mechanism is to be stopped for this subscriber in the SGSN, then the GGSN shall 
include the MS Info Change Reporting Action IE in the message and shall set the value of the Action field 
appropriately. 

Table 7.3.15-1: Information Element in Change Notification Response 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


IMSI 


M 


None 


1 


IMSI 





Cause 


M 


None 


1 


Cause 





Change Reporting 
Action 





If the MS Info Change Reporting mechanism is to be 
stopped for this subscriber in the SGSN, then the GGSN 
shall include the MS Info Change Reporting Action IE with 
the appropriate Action field 


1 


Change Reporting 
Action 





Private Extension 





Vendor or operator specific information 





Private Extension 


vs 



7.3.16 Relocation Cancel Request 

A Relocation Cancel Request message shall be sent from the source MME/SGSN to the target MME/SGSN on 
S3/S10/S16 interface as part of handover Cancel procedure. 

Table 7.3.16-1 specifics the presence of the lEs in the message. 

Table 7.3.16-1: Information Elements in Relocation Cancel Request 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


IMSI 


M 


None 


1 


IMSI 





Private Extension 





None 


1 


Private Extension 


VS 
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7.3.17 Relocation Cancel Response 



A Relocation Cancel Response message shall be sent as a response to a previous Relocation Cancel Request message 
during handover Cancel procedure. 

Possible Cause values are: 

- 'Request Accepted'. 

- 'IMSI not known'. 
'System failure'. 
'Mandatory IE incorrect'. 
'Mandatory IE missing'. 
'Optional IE incorrect'. 
'Invalid message format'. 

Table 7.3.17-1 specifics the presence of the lEs in the message. 

Table 7.3.17-1 : Information Elements in Relocation Cancel Response 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





Private Extension 





None 


1 


Private Extension 


vs 



7.4 CS Fallback related messages 



7.4.1 



Suspend Notification 



The Suspend Notification message is sent on S 11 by the MME to the SOW as part of the CS fallback from E-UTRAN 
access to UTRAN/GERAN CS domain access related procedures. 

Table 7.4.1-1: Information Element in Suspend Notification 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


IMSI 


M 




1 


IMSI 





Private Extension 





Vendor or operator specific information 





Private Extension 


VS 



7.4.2 Suspend Acknowledge 

The Suspend Acknowledge message is sent on S 1 1 by the SGW to the MME as part of the CS fallback from E-UTRAN 
access to UTRAN/GERAN CS domain access related procedures. 

Table 7.4.2-1 : Information Element in Suspend Acknowledge 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


IMSI 


M 




1 


IMSI 





Private Extension 





Vendor or operator specific information 





Private Extension 


VS 
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7.4.3 Resume Notification 

The Resume Notification message is sent on S 1 1 by the MME to the SGW as part of the resume procedure returning 
from CS fallback to E-UTRAN. 

Table 7.4.3-1 : Information Element in Resume Notification 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


IMSI 


M 




1 


IMSI 





Private Extension 





Vendor or operator specific information 





Private Extension 


vs 



7.4.4 Resume Acknowledge 

The Resume Acknowledge message is sent on S 1 1 by the SGW to the MME as part of the resume procedure returning 
from CS fallback to E-UTRAN. 

Table 7.4.4-1 : Information Element in Resume Acknowledge 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


IMSI 


M 




1 


IMSI 





Private Extension 





Vendor or operator specific information 





Private Extension 


VS 



7.4.5 CS Paging Indication 

The CS Paging Indication shall be sent on the S3 interface by the MME to the associated SGSN when ISR is activated 
as part of mobile terminated CS services. The MME gets the related information from SGsAP-P AGING-REQUEST 
message as specified in 3GPP TS29.1 18 [21].Table 7.4.5-1 specifies the presence requirements and the conditions of 
the lEs in the message. 

Table 7.4.5-1: Information Element in CS Paging Indication 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


IMSI 


M 


None 


1 


IMSI 





VLR Number 


M 


None 


1 


FFS 





TMSI 







1 


TMSI 





Location area 
identifier 







1 


ULI 





Global CN-ld 







1 


Global CN-ld 






Editor's notes: the lEs in this table needs to be examined once the CSFB stage 2 will be stabilized. 

7.5 Non-3GPP access related messages 
7.5.1 Create Forwarding Tunnel Request 

Editor's Note: It is FFS if this request message and corresponding response message will be sent per PDN 
connection basis. 

A Create Forwarding Tunnel Request message shall be sent by a MME to a Serving GW as a part of the MME 
configures resources for indirect data forwarding during active handover procedure from E-UTRAN to CDMA 2000 
HRPD access. 

Table 7.5.1-1 specifies the presence requirements and the conditions of the lEs in the message. 
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Table 7.5.1-1 : Information Elements in a Create Forwarding Tunnel Request 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


S103PDN Data 
Forwarding Info 


M 


The MME shall include the forwarding Infomation for all 
PDN connections of the UE requesting data forwarding 
towards the PDSN in the message as S103 PDN Data 
Forwarding Info information elements. The Serving GW 
shall forward downlink data to the PDSN via the GRE 
tunnel identified by the PDSN Address and PDSN GRE 
Key included in this information element when it receives 
downlink data forwarded from the eNodeB belonging to the 
corresponding EPS bearers of the PDN connection. 


1 


S103PDF 






7.5.2 Create Forwarding Tunnel Response 

A Create Forwarding Tunnel Response message shall be sent by a Serving GW to a MME as a response to a Create 
Forwarding Tunnel Request message. 

Table 7.5.2-1 specifies the presence requirements and the conditions of the lEs in the message. 

The Cause value indicates if Data Forwarding Resources has been created in the Serving GW or not. Data Forwarding 
Resources have not been created in the Serving GW if the Cause differs from 'Request accepted'. Possible Cause values 
are: 

"Request Accepted". 

"No resources available". 

- "System failure". 

"Mandatory IE incorrect". 

"Mandatory IE missing". 

"Optional IE incorrect". 

"Invalid message format". 

Only the Cause IE shall be included in the response if the Cause IE contains another value than 'Request accepted'. 

Table 7.5.2-1 : Information Elements in a Create Forwarding Tunnel Response 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


None 


1 


Cause 





S1-U Data 
Forwarding Info 


C 


S1-U Data Forwarding Info shall be included in the 
message if the Cause contains the value 'Request 
accepted'. For each EPS bearer requesting data 
forwarding which is included in the S103 PDN Data 
Forwarding Info fields of corresponding Create Forwarding 
Tunnel Request message, the Serving GW shall assign a 
Serving GW S1-U Address and Serving GW S1-U TEID 
pair and included it in the response message as S1-U Data 
Forwarding Info information element. The eNodeB shall 
forward downlink data of the EPS bearer to the Serving 
GW via the GTP-U tunnel identified by the Serving GW S1- 
U Address and Serving GW S1-U TEID. 


1 


S1UDF 
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7.6 Reliable Delivery of Signalling Messages 

Each path maintains a queue with signalling messages to be sent to the peer. The message at the front of the queue, if it 
is a request for which a response has been defined, shall be sent with a Sequence Number, and shall be held in a path 
list until a response is received. The same provision is applicable to notification messages with an associated 
acknowledge message. Each path has its own list. The Sequence Number shall be unique for each outstanding request 
message sourced from the same IP/UDP endpoint. A node running GTP may have several outstanding requests while 
waiting for responses. A single request shall be answered with a single response, regardless whether it is per UE, per 
APN, or per bearer. A request / response pair of messages shall have the same sequence number. 

The Sequence Number shall be unique for each outstanding notification message sourced from the same IP/UDP 
endpoint. A node running GTP may have several outstanding notifications while waiting for acknowledge messages. A 
single notification shall be answered with a single acknowledge, regardless whether it is per UE, per APN, or per 
bearer. A notification / acknowledge pair of messages shall have the same sequence number. 

In the specific case of GTP Command Messages which do not have an explicit response, but which trigger a Request 
Message, the sequence number used by Command Message shall be the same for all three messages: the Command, the 
triggered Request and the corresponding Response messages. 

A sequence number used for a Command Message and its associated messages shall have the most significant bit set to 
1 . A sequence number used for a Request Message not triggered by a Command Message shall have the most 
significant bit set to 0. 

This setting of the most significant bit of the sequence number is done to avoid potential clashes between the sequence 
number selected for a Command Message, and the sequence number selected by a GTP peer for a Request Message 
which was not triggered by a Command Message. 

A timer shall be started when a signalling request message (for which a response has been defined) is sent. A signalUng 
message request or response has probably been lost if a response has not been received before the timer expires. 

A timer shall be started when a notification message (for which an acknowledge messages has been defined) is sent. A 
notification or acknowledge message has probably been lost if a response has not been received before the timer 
expires. 

A timer shall be started when a command message is sent. A command or request message has probably been lost if a 
request has not been received before the timer expires. 

Editor's Note: it is FFS how many response timers are needed and how the timers shall be handled. 

Once a timer expires, the request is then retransmitted if the total number of request attempts is less than 
N3-REQUESTS times. The timer shall be implemented in the control plane application as well as user plane application 
for Echo Request / Echo Response. The timers and the number of retries (N3-REQUESTS) shall be configurable per 
procedure. 

Editor's Note: In case of a node shall send a response message based on the response of another GTP message, the 
total waiting time of the inner loop response should be smaller than the waiting time of the outer loop 
response. 

All received request messages shall be responded to and all response messages associated with a certain request shall 
always include the same information. Duplicated response messages shall be discarded. A response message without a 
matching outstanding request should be considered as a duplicate. 

If a GTPv2 node is not successful with the transfer of a signalling message, e.g. a Create Bearer Context Request 
message, it shall inform the upper layer of the unsuccessful transfer so that the controlling upper entity may take the 
necessary measures. 



ETSI 



3GPP TS 29.274 version 8.0.0 Release 8 68 ETSI TS 1 29 274 V8.0.0 (2009-01 ) 

7.7 Error Handling 

7.7.1 Protocol Errors 

A protocol error is defined as a message or Information Element received from a peer entity with unknown, unforeseen 
or erroneous content. The term silently discarded is used in the following subclauses to mean that the receiving GTP 
entity's implementation shall discard the message without further processing, or if possible discard the optional IE and 
continue processing. The receiving entity should however log the event including the erroneous message and should 
include the error in a statistical counter. Silently Discarding a message or IE(s) within a message should only be used 
for messages or IE(s) that can be safely ignored. IE(s) that can safely be ignored by a receiver are ones with the CR bit 
set to 0. 

Editor's Note: It is FFS how a conditional IE should be treated by a receiving entity.A receiving node may deviate from 
the required error handling requirements, in the case of sending back messages with cause values, in order to limit 
traffic load or mitigate against a denial-of-service attack. 

An information element with 'Mandatory' in the 'Presence requirement' column of a message definition shall always be 
present in that message. 

An information element with 'Conditional' in the 'Presence requirement' column of a message definition shall be sent 
when the conditions detailed in the 'Presence requirement' are met. 

The Version Not Supported Indication message shall be considered as Response for the piupose of this subclause. The 
subclauses 7.7.2 to 7.7.14 shall be applied in decreasing priority. 

Generally, in subclauses 7.7.2 to 7.7.14 when an error in an incoming GTP message is detected the GTP entity should 
log the error even if the IE or message fault is ignored or discarded. If the received message is a GTP response for a 
pending GTP request the GTP transaction layer shall stop retransmission of the matching request and notify the GTP 
application layer of the error even if the response is itself discarded. 

7.7.2 Different GTP Versions 

If a receiving peer node receives a GTP message of an unsupported version, that node shall return a GTP "Version Not 
Supported Indication message indicating in the Version field of the GTP header the latest GTP version that that node 
supports. The received GTP-PDU shall then be discarded. 

7.7.3 GTP Message Too Short 

When a GTP message is received, and it is too short to contain the GTP header for the GTP version that the sender 
claims to use, the GTP-PDU message shall be silently discarded. 

7.7.4 Unknown GTP Signalling Message 

When a message using a Message Type value defining an Unknown GTP signalling message is received, it shall be 
silently discarded. 

7.7.5 Unexpected GTP Signalling Message 

When an unexpected GTP control plane message is received, e.g. a Response message for which there is no 
corresponding outstanding Request it shall be silently discarded. 

7.7.6 Missing Mandatory or Conditional Information Elements 

The receiver of a GTP signalling Request message with a missing mandatory information element shall discard the 
request and shall send a Response with Cause set to 'Mandatory IE missing' together with a value of the missing 
mandatory IE. 

The receiver of a Response with a missing mandatory information element shall notify the upper layer. 



£75/ 



3GPP TS 29.274 version 8.0.0 Release 8 69 ETSI TS 1 29 274 V8.0.0 (2009-01 ) 

Editor's note: A missing Conditional Information Element in a GTPv2 message (grouped IE) whose condition is true 
may or may not be treated the same way as an Invalid Mandatory IE. If it is treated as mandatory IE 
however, the Cause 'Mandatory IE missing' is replaced with 'Conditional IE missing'. 

7.7.7 Invalid Length 

TLIV format information element shall have a variable length. In a received GTP signalling message Request, a 
mandatory TLIV format information element may have a Length different from the Length defined in the version that 
this message claims to use. In this case, this information element shall be discarded, the error should be logged, and a 
Response shall be sent with Cause set to 'Mandatory IE incorrect' together with a copy of the offending mandatory IE. 

In a received GTP signalling Response message, if a mandatory TLIV format information element has a Length 
different from the Length defined in the version that this message claims to use, then the requesting entity shall treat the 
GTP signalling procedure as having failed. A message shall be sent with Cause set to 'Mandatory IE incorrect' together 
with a copy of the offending mandatory IE. 

7.7.8 Invalid Mandatory or Conditional Information Element 

The receiver of a GTP signalling message Request including a mandatory information element with a Value that is not 
in the range defined for this information element value shall discard the request, should log the error, and shall send a 
response with Cause set to 'Mandatory IE incorrect' together with a copy of the offending mandatory IE. 

The receiver of a GTP signalling message Response including a mandatory information element with a Value that is not 
in the range defined for this information element shall notify the upper layer that a message with this sequence number 
has been received and should log the error. It shall send a response with Cause set to 'Mandatory IE incorrect' together 
with a copy of the offending mandatory IE. 

If a GSN receives an information element with a value which is shown as reserved, it shall treat that information 
element as invalid and should log the error. It shall send a response with Cause set to 'Reserved Message Value 
Received' together with a copy of the offending message. 

The principle is: the use of reserved values invokes error handling; the use of spare values can be silently discarded and 
so in the case of lEs with spare values used, processing shall be continued ignoring the spare values. 

Editor's note: A missing Conditional Information Element in a GTPv2 message (grouped IE) whose condition is true 
may or may not be treated the same way as an Invalid Mandatory IE. If it is treated as mandatory IE 
however, the Cause 'Mandatory IE missing' is replaced with 'Conditional IE missing'. 



7.7.9 Invalid Optional Information Element 



The receiver of a GTP signalling message including an optional information element with a Value that is not in the 
range defined for this information element value shall discard this IE, but shall treat the rest of the message as if this IE 
was absent and continue processing. 

If a GTP entity receives an information element with a value which is shown as reserved, it shall treat that information 
element as not being in the range defined for the information element. 

The receiver shall not check the content of an information element field that is defined as 'spare'. 

7.7.10 Unknown Information Element 

An information element with an unknown Type value and CR=0 shall be ignored by the receiver of the message. This 
information element shall be skipped using its Length value. 

The receiver of a GTP signalling message Request including an information element with an unknown Type value and 
CR=1 shall discard the request, and shall send a response with Cause set to 'Unknown CR IE' together with a copy of 
the offending unknown IE. 

Editor's note: if is FFS if the receiver of a GTP signalling message Response including an information element with 
an unknown Type value and CR=1 shall discard the Response. 
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7.7.1 1 Out of Sequence Information Elements 

Editor's Note: Since all IE are TLIV encoded the IE order is not needed to parse a GTPv2-C encoded message so no 
error occurs in this version of GTP. It is FFS however if a ordering on sending side may still be required 
by GTPv2 to allow GTPv2 parsers to be more efficient but it should not invoke a functional fault on 
reception. 

7.7.12 Unexpected Information Element 

An information element with a Type value which is defined in section 8. 1 of the present specification but whose 
Instance Value is not expected in the received GTP signalling message according to the grammar defined in section 7.1 
to 7.5 of the present specification shall be ignored (skipped) and the rest of the message processed as if this information 
element was not present. 

NOTE: An Information Element in an encoded GTPv2 message or grouped IE is identified by the pair of IE Type 
and Instance value. 

Editor's note: It is FFS how type value, instance value and CR field relate to each other 

7.7.13 Repeated Information Elements 

An Information Element is repeated if there is more than one IE with the same IE Type and Instance in the scope of the 
GTP message (scope of the grouped IE). Such an IE is a member in a list. 

If an information element is repeated in a GTP signalling message in which repetition of the information element is not 
specified, only the contents of the information element appearing first shall be handled and all subsequent repetitions of 
the information element shall be ignored. When repetition of information elements is specified, only the contents of 
specified repeated information elements shall be handled and all subsequent repetitions of the information element shall 
be ignored. 

7.7.14 Incorrect Optional Information Elements 

All optional information elements that are incorrect in a GTP signalling message shall be treated as not present in the 
message. However, if the receiving node cannot handle the message correctly because of the incorrect information 
element, the receiving node should log the error and shall return a response with Cause set to 'Optional IE incorrect' 
together with the offending IE. 

7.8 Path Failure 

Restoration and Recovery procedures, including path failure, are specified in 3GPP TS 23.007 [17]. 
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7.9 Restoration and Recovery 

Restoration and Recovery procedures are specified in 3GPP TS 23.007 [17]. 

7.9.x Delete PDN Connection Set Request 

This message is sent on S5, S8, or Sll interfaces. The message sent by MME shall be forwarded by the SGW to PGW. 
The message sent by the PGW shall be forwarded by SGW to MME. 

A node sends this message when a partial failure affects a set of its PDN connections for which CSID has been 
previously assigned. The receiving node identifies the set of PDN connections associated with the CSID from its PDN 
connection table, and marks them for deletion. 

Table 7.9.X: Information Elements in a Delete PDN Connection Set Request 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


CSID 


M 


IVIore tlian one CSID may appear 


1 


CSID 





Cause 







1 


Cause 





Private Extension 





None 


1 


Private Extension 


VS 



7.9.Y Delete PDN Connection Set Response 

This message is sent as a response to the Delete PDN Connection Set Request. 

Table 7.9. Y: Information Elements in a Delete PDN Connection Set Response 



Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Ins. 


Cause 


M 


"Success" indicates that the peer node successfully 
deleted the PDN connection set 


1 


Cause 





Private Extension 





None 


1 


Private Extension 


VS 



7.10 Fallback to GTPv1 mechanism 

An EPC entity shall assume that each GTP processing node that it is about to communicate with is GTPv2 capable, i.e. 
before the first GTP tunnel is setup for a given UE/node, the EPC node shall always send a version 2 (GTPv2) message 
to a peer node. 

A GTPv2 entity shall fallback to GTPvl only if 

a "Version Not Supported" message in GTPvl format as specified in 3GPP TS 29.060 [4] is received from the 
peer node; 

Fallback to GTPvl shall not occur on already established GTP tunnels without change of the peer nodes of the 
communication bearer. 

7.11 Fallback to GTPvO 

Fallback from GTPv2 to GTPvO shall not be supported. Therefore, GTPv2 entity should not listen to the well-known 
GTPvO port 3386. If GTPv2 entity listens to the GTPvO port, the entity shall silently discard any received GTPvO 
message. 
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8 GTP-C Information Elements 

8.1 Information Element Types 

A GTP control plane (signalling) message may contain several information elements. In order to have forward 
compatible type definitions for the GTPv2 information elements, all of them shall be TLV coded. GTPv2 information 
element type values are specified in the Table 8.1-1. In order to improve the efficiency of troubleshooting, it is 
recommended that the information elements should be arranged in the signalling messages as well as in the grouped 
lEs, according to the order the information elements are listed in the message definition table or grouped IE definition 
table in section 7. However the receiving entity shall be prepared to handle the messages with information elements in 
any order. 

Within information elements, certain fields may be described as spare. These bits shall be transmitted with the value set 
to 0. To allow for future features, the receiver shall not evaluate these bits. 
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Table 8.1-1 : Information Element types for GTPv2 



IE Type value 
(Decimal) 


Information elements 


Comment / Reference 





Reserved 




1 


International Mobile Subscriber Identity (IMSI) 


Extendable / 8.3 


2 


Cause (without embedded offending IE) 


Extendable / 8.4 


3 


Recovery (Restart Counter) 


Extendable / 8.5 


4-50 


Reserved for SI 01 interface 


Extendable / See 3GPP TS 29.276 [14] 


51-70 


Reserved for Sv interface 


Extendable / See 3GPP TS 29.280 [15] 


71 


Access Point Name (APN) 


Extendable / 8.6 


72 


Aggregate Maximum Bit Rate (AMBR) 


Extendable / 8.7 


73 


EPS Bearer ID (EBI) 


Extendable / 8.8 


74 


IP Address 


Extendable / 8.9 


75 


Mobile Equipment Identity (MEI) 


Extendable/ 8.10 


76 


MSISDN 


Extendable/ 8.11 


77 


Indication 


Extendable/ 8.12 


78 


Protocol Configuration Options (PCO) 


Extendable/ 8.13 


79 


PDN Address Allocation (PAA) 


Extendable/ 8.14 


80 


Bearer Level Quality of Service (Bearer QoS) 


Extendable/ 8.15 


81 


Flow Quality of Service (Flow QoS) 


Extendable/ 8.16 


82 


RAT Type 


Extendable/ 8.17 


83 


Serving Network 


Extendable/ 8.18 


84 


TEID-C 


Extendable/ 8.19 




TEID-U 


Extendable /8.19a 




TEID-U with EPS Bearer ID 


Extendable /8.19b 


85 


EPS Bearer Level Traffic Flow Template (Bearer TFT) 


Extendable / 8.20 


86 


Traffic Aggregation Description (TAD) 


Extendable / 8.21 


87 


User Location Info (ULI) 


Extendable / 8.22 


88 


Fully Qualified Tunnel Endpoint Identifier (F-TEID) 


Extendable / 8.23 


89 


TMSI 


Extendable / 8.24 


90 


Global CN-ld 


Extendable / 8.25 


91 


Legacy Quality of Service (Legacy QoS) 


Extendable / 8.26 


92 


SI 03 PDN Data Forwarding Info (S103PDF) 


Extendable / 8.27 


93 


S1-U Data Forwarding Info (S1UDF) 


Extendable / 8.28 


94 


Delay Value 


Extendable / 8.29 


95 


Bearer ID List 


Extendable / 8.30 


96 


Bearer Context 


Extendable / 8.31 


97 


SI 01 -IP-Address 


Extendable / 8.32 


98 


S102-IP-Address 


Extendable / 8.33 


99 


Charging ID 


Extendable / 8.34 


100 


Charging Characteristics 


Extendable / 8.35 


101 


Trace Information 


Extendable / 8.36 


102 


Bearer Flags 


Extendable / 8.37 


103 


Paging Cause 


Extendable / 8.38 


104 


PDN Type 


Extendable / 8.39 


105 


Procedure Transaction ID 


Extendable / 8.40 


106 


DRX Parameter 


Extendable / 8.41 


107 


UE Network Capability 


Extendable / 8.42 


108 


PDU Numbers 


Extendable / 8.46 


109 


MM Context (GSM Key and Triplets) 


Extendable / 8.43 


110 


MM Context (UMTS Key, Used Cipher and Quintuplets) 


Extendable / 8.43 


111 


MM Context (GSM Key, Used Cipher and Quintuplets) 


Extendable / 8.43 


112 


MM Context (UMTS Key and Quintuplets) 


Extendable / 8.43 


113 


MM Context (EPS Security Context, Quadruplets and Quintuplets) 


Extendable / 8.43 


114 


MM Context (UMTS Key, Quadruplets and Quintuplets) 


Extendable / 8.43 


115 


PDN Connection 


Extendable / 8.44 


116 


GRE Key 


Extendable / 8.45 


117 


Bearer Control Mode 


Extendable / 8.68 


118 


EPS Bearer Contexts Prioritization (Contexts Prioritization) 


Extendable / 8.47 


119 


LMA IP Address 


Extendable / 8.48 


120 


P-TMSI 


Extendable / 8.49 


121 


P-TMSI Signature 


Extendable / 8.50 


122 


Hop Counter 


Extendable / 8.51 


123 


Authentication Quintuplet 


Extendable / 8.52 


124 


Authentication Quadruplet 


Extendable / 8.53 


125 


Complete Request Message 


Extendable / 8.54 


126 


GUTI 


Extendable / 8.55 


127 


F-Container 


Extendable / 8.56 


128 


F-Cause 


Extendable / 8.57 


129 


Selected PLMN ID 


Extendable / 8.58 


130 


Target Identification 


Extendable / 8.59 


131 


Cell Identification 


Extendable / 8.67 
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IE Type value 
(Decimal) 


Information elements 


Comment / Reference 


132 


NSAPI 


Extendable / 8.60 


133 


Packet Flow ID 


Extendable / 8.61 


134 


RAB Context 


Extendable / 8.62 


135 


Source RNC PDCP Context Info 


Extendable / 8.63 


136 


UDP Source Port Number 


Extendable / 8.64 


137 


APN Restriction 


Extendable / 8.65 


138 


Selection Mode 


Extendable / 8.66 


139 


Change Reporting Action 


Extendable / 8.69 


140 


Cause including an embedded offending IE 


Extendable / 8.4 


141 


PDN Connection Set Identifier (CSID) 


Extendable / 8.70 


142-254 


Spare. For future use. 


FFS 


255 


Private Extension 


Extendable / 8.71 



8.2 



Information Element Format 



Figure 8.2-1 depicts the format of an information element, which has the following mandatory fields: 

Type field: This field indicates the type of Information Element. The valid values of the IE type are defined in 
clause 8.1. 

Comprehension Required (CR) flag: If CR flag is set to 1, the comprehension of the IE is required. This flag may 
have variable values (0 or 1) only within optional lEs, and shall be set to 1 for all mandatory or conditional lEs. 

Editor's note: Currently it is assumed that CR = for GTP-U. 

Length: This field contains the length of the information element excluding the first four octets, which are 
common for all information elements (Type, Length and the octet 4) and is denoted "n" in Figure 8.2-1. For all 
the length fields, bit 8 of the lowest numbered octet is the most significant bit and bit 1 of the highest numbered 
octet is the least significant bit. 



Octets 

1 
2-3 

4 
5-(n+4) 


8 


7 


Bits 
6 5 4 


3 2 


1 




Type 




Length = n 




CR 


Spare 


Instance 




IE specific data 



Figure 8.2-1 : Information Element FormatThe Comprehension Required (CR) flag shall be used in the following 



way: 



CR flag is set to 1 in a Request message: if the receiving GTP entity cannot comprehend the IE, then the receiver 
shall discard the request, should log the error, and shall send a response with an appropriate Cause value. 

Editor's note: it is FFS if Cause should be amended by complete IE or only its Type. 

CR flag is set to 1 in a Response message: if the receiving GTP entity cannot comprehend the IE, then the 
receiver shall notify the upper layer that a message with this unknown IE has been received and should log the 
error. 

Editor's note: it is FFS if an error notification should be sent. 

Instance is documented in section 6.1. 

An IE is said to be TLIV (Type, Length, Instance, Value) encoded. 
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8.3 International Mobile Subscriber Identity (IMSI) 

International Mobile Subscriber Identity (IMSI) is transferred via GTP tunnels. The sending entity copies the value part 
of the IMSI into the Value field of the IMSI IE. IMSI is defined in 3GPP TS 23.003 [2]. 

Editor's note: IMSI coding will be defined in 3GPP TS 24.301 [3]. 

Editor's note: In the first release of GTPv2 spec (TS 29.274v8.0.0) n = 8. That is, the overall length of the IE is 11 
octets. In future releases of the spec additional octets may be specified. The legacy receiving entity 
simply ignores the unknown octets. 



Octets 

1 

2-3 

4 

5-(n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 1 (decimal) 




Length = n (decimal) 


CR Spare Instance 


International IVlobile Subscriber Identity (IMSI) 



Figure 8.3-1: IMSI 



8.4 



Cause 



Cause IE is coded as this is depicted in Figure 8.4-1. 



Octets 

1 

2-3 

4 

5 

6-(n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 2 (decimal) 




Length = n (decimal) 


CR Spare Instance 


Cause value 


These octet(s) is/are present only if explicitly specified 



Figure 8.4-1 : Cause 

The Cause value shall be included in the response message. In a response message, the Cause value indicates the 
acceptance or the rejection of the corresponding request message. The Cause value shall indicate the explicit reason for 
the rejection. 

If the rejection is due to a faulty IE, the offending IE shall be included as embedded IE within the cause "IE". In this 
case, the Cause IE becomes a grouped IE. The IE would be coded as depicted if Figure 8.4-2. 



Octets 

1 
2-3 

4 

5 

6 
7-8 

9 
9-(n+9) 


Bits 
8 7 6 5 4 3 2 


1 




Type= 140 (decimal) 




Length = n + 5 


CR Spare Instance 


Cause value 


Type = <type of the offending IE> 


Length = n (decimal) 


CR Spare Instance 


Value of the offending IE 



Figure 8.4-2: Cause including an embedded "offending IE" 

The Cause may also be included in the request message. In a request message, the Cause value indicates the reason for 
the request. 

"Request accepted" is returned when the GTPv2 entity has accepted a control plane request. 
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Table 8.4-1 : Cause values 



Message Type 


Cause value 
(decimal) 


Meaning 







Reserved. Sliall not be sent and if received tlie Cause shall be treated as an 
invalid IE 


Request 


1 


Paging Cause 


2 


Local Detach 


3 


Complete Detach 


4-15 


Spare. This value range is reserved for Cause values in a request message 


Acceptance 
Response 


16 


Request accepted 


17 


Request accepted partially 


18 


New PDN type due to subscription limitation 


19 


New PDN type due to network preference 


20 


New PDN type due to single address bearer only 


21-63 


Spare. This value range is reserved for Cause values in acceptance response 
message 


Rejection 
Response 


64 


Context Non Existent/Found 


65 


Invalid IVIessage Format 


66 


Version not supported by next peer 


67 


Invalid length 


68 


Service not supported 


69 


IVIandatory IE incorrect 


70 


Mandatory IE missing 


71 


Optional IE incorrect 


72 


System failure 


73 


No resources available 


74 


Semantic error in the TFT operation 


75 


Syntactic error in the TFT operation 


76 


Semantic errors in packet filter(s) 


77 


Syntactic errors in packet filter(s) 


78 


Missing or unknown APN 


79 


Unexpected repeated IE 


80 


GRE key not found 


81 


Reallocation failure 


82 


Denied in RAT 


83 


Preferred PDN type not supported 


84 


All dynamic addresses are occupied 


85 


UE context without TFT already activated 


86 


Protocol type not supported 


87 


UE not responding 


88 


UE refuses 


89 


Service denied 


90 


Unable to page UE 


91 


No memory available 


92 


User authentication failed 


93 


APN access denied - no subscription 


94-255 


Spare. This value range is reserved for Cause values in rejection response 
message 
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8.5 Recovery (Restart Counter) 

Recovery IE is coded as this is depicted in Figure 8.5-1. 

Editor's note: In the first release of GTPv2 spec (TS 29.274v8.0.0) n = 1 . That is, the overall length of the IE is 4 
octets. In future releases of the spec additional octets may be specified. The legacy receiving entity 
simply ignores the unknown octets. 



Octets 

1 
2-3 

4 
5-(n-i-4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 3 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




Recovery (Restart Counter) 



Figure 8.5-1 : Recovery (Restart Counter) 



8.6 Access Point Name (APN) 



Access Point Name (APN) is transferred via GTP tunnels. The sending entity copies the value part of the APN into the 
Value field of the APN IE. 

Editor's note: APN will be defined in 3GPP TS 23.003 [2]. 



Octets 

1 

2-3 

4 

5-(n-^4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 71 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




Access Point Name (APN) 



Figure 8.6-1 : Access Point Name (APN) 



8.7 Aggregate Maximum Bit Rate (AMBR) 

Aggregate Maximum Bit Rate (AMBR) is transferred via GTP tunnels. The sending entity copies the value part of the 
AMBR into the Value field of the AMBR (APN- AMBR) IE. 

Editor's note: AMBR will be defined in 3GPP TS 23.003 and its coding in TS 24.301. 



Octets 

1 

2-3 

4 

5-(n-i-4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 72 (decimal) 




Length = n (decimal) 


CR Spare Instance 


Aggregate Maximum Bit Rate (AIVIBR) 



Figure 8.7-1 : Aggregate IVIaximum Bit Rate (AIVIBR) 
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8.8 EPS Bearer ID (EBI) 

EPS Bearer ID (EBI) is coded as this is depicted in Figure 8.8-1. 

Editor's note: In the first release of GTPv2 spec (TS 29.274v8.0.0) n = 1 and all spare bits in Octet 4 are set to 0. 
That is, the overall length of the IE is 4 octets. In future releases of the spec additional octets may be 
specified and new semantic for the spare bits may be defined. The legacy receiving entity simply ignores 
the unknown octets and values in the spare bits. 



Octets 

1 
2-3 

4 

5 

6-(n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 73 (decimal) 




Length = n (decimal) 


CR 1 Spare 


Instance 


Spare (all bits set to 0) 


EPS Bearer ID (EBI) 


These octet(s) is/are present only if explicitly specified 



Figure 8.8-1 : EPS Bearer ID (EBI) 



8.9 



IP Address 



IP Address is coded as this is depicted in Figure 8.9-1. The Length field may have only two values (4 or 16) that 
determine if the Value field contains IPv4 or IPv6 address. 



Octets 

1 

2-3 

4 

5-(n+4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 74 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




IPv4 or IPv6 Address 



Figure 8.9-1 : IP address 



8.10 Mobile Equipment Identity (MEI) 

Mobile Equipment Identity (MEI) is transferred via GTP tunnels. The sending entity copies the value part of the MEI 
into the Value field of the MEI IE. MEI is defined in 3GPP TS 23.003 [2]. 

Editor's note: MEI coding will be defined in TS 24.301. 



Octets 

1 

2-3 

4 

5-(n+4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 75 (decimal) 




Length = n (decimal) 


CR Spare Instance 


Mobile Equipment (IVIE) Identity 



Figure 8.10-1 : Mobile Equipment (ME) Identity (MEI) 
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8.11 MSISDN 

MSISDN is transferred via GTP tunnels. The sending entity copies the value part of the MSISDN into the Value field of 
the MSISDN IE. MSISDN is defined in 3GPP TS 23.003 [2]. 

Editor's note: MSISDN coding will be defined in TS 24.301. 



Octets 

1 
2-3 

4 
5-(n-^4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 76 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




MSISDN 



Figure 8.1 1-1: MSISDN 



8.12 Indication 



Indication is coded as this is depicted in Figure 8.12-1. 



Octets 

1 

2-3 
4 
5 

6 

7-(n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 77 (decimal) 




Length = n (decimal) 


CR 


Spare 


Instance 


DAF 


DTF 


HI 


DPI 


01 


ISRSI 


ISRAI 


SGW 
CI 


Reserved 


PT 


TDI 


SI 


MSV 


These octet(s) is/are present only if explicitly specified 



Figure 8.12-1: Indication 



The following bits within Octet 5 indicate: 



- Bit 8 - DAF (Dual Address Bearer Flag): This bit shall be set when the UE requests PDN type IPv4/v6 and all 
SGSNs which the UE may be handed over to are Release 8 or above supporting dual addressing, which is 
determined based on node pre-configuration by the operator.. 

- Bit 7 - DTF (Direct Tunnel Flag): This bit shall be set when the UE is in UTRAN/GERAN network and Direct 
Tunnel is selected - Bit 6 - HI (Handover Indication): If this bit is set to 1, it indicates that UE handover from 
non-3GPP access to 3GPP access system during attach procedure or UE requested PDN connectivity procedure. 

Bit 5 - DEI (Direct Forwarding Indication): If this bit is set to 1, it indicates that the direct forwarding between 
source eNodeB/RNC and target eNodeB/RNC during the handover procedure is applied. 

Bit 4 - OI (Operation Indication): If this bit is set to 1, it denotes that the receiving entity shall continue 
forwarding this message to the next GTP node or the SGW shall send the Modify Bearer Request to the PGW 
during TAU/RAU with a SGW Change procedure. 

Bit 3 - ISRSI (Idle mode Signalling Reduction Supported Indication): If this is set to 1, it indicates that the 
old/source SGSN/MME is capable to activate ISR. 

Bit 2 - ISRAI (Idle mode Signalling Reduction Activation Indication): If this bit is set to 1, it indicates that the 
ISR is estabUshed between MME and S4 SGSN during TAU/RAU without a SGW change procedure or during 
Inter RAT handover without SGW change procedure. The SGW shall retain the resources for other CN node that 
has bearer resources on the SGW reserved and the old/source SGSN/MME shall maintain the UE's contexts and 
activate ISR. 

- Bit 1 - SGWCI (SGW Change Indication): If this bit is set to 1, it indicates that the target MME/SGSN has 
selected a new SGW during TAU/RAU or handover with a SGW change procedure. 

The following bits within Octet 6 indicate: 

Bit 8 to 5 - Reserved for future use and set to zero. 
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- Bit 4 - PT (Protocol Type) If this bit set to 1, it indicates that the protocol type for S5/S8 interface is PMIP; this 
bit is set to to indicate the protocol type for S5/S8 interface is GTP. 

Bit 3 - TDI (Teardown Indication): If this bit is set to 1, it indicates that all bearers of the PDN connection shall 
be torn down. 

.- Bit 2 - SI (Scope Indication): If this bit is set to 1, it indicates that all GTP-U tunnels of the PDN connection 
over SI interface should be released. This flag is set for messages during SI release procedure. 

- Bit 1 - MSV (MS Validated): If this bit is set to 1, it indicates that the new MME/SGSN has successfully 
authenticated the UE. 

8.13 Protocol Configuration Options (PCO) 

Protocol Configuration Options (PCO) is transferred via GTP turmels. The sending entity copies the value part of the 
PCO into the Value field of the PCO IE. 

Editor's note: PCO will be defined in 3GPP TS 23.003 and its coding in TS 24.301. 



Octets 

1 

2-3 

4 

5-(n-i-4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 78 (decimal) 




Length = n (decimal) 


CR Spare Instance 


Protocol Configuration Options (PCO) 



Figure 8.13-1 : Protocol Configuration Options (PCO) 
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8.14 PDN Address Allocation (PAA) 

The PDN Address Allocation is coded as depicted in Figure 8.14-1. 
NOTE: In Rel 8, Prefix length has a fixed value of /64. 



Octets 

1 

2-3 
4 
5 


8 7 


Bits 
6 5 4 3 2 1 




Type = 79 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 


Spare | PDN Type 


6-(n-i-4) 


PDN Address and Prefix 





Figure 8.14-1 : PDN Address Allocation (PAA) 



Table 8.14-1 : PDN Address Allocation 



PDN type value (octet 4) 


Bits 






3 2 


1 







1 


IPv4 


1 





IPv6 


1 


1 


IPv4/IPv6 



Bits 8-4 of octet 5 are spare and shall be coded as zero. 

PDN Address and Prefix (octet 6 to n-i-4) 

If PDN type value indicates IPv4, an IPv4 address is present in the PDN Address and 
Prefix from octet 6 to octet 9. Bit 8 of octet 6 represents the most significant bit of the 
IPv4 address and bit 1 of octet 9 the least significant bit. 

If PDN type value indicates IPv6, octet 6 contains the IPv6 Prefix Length. Octets 7 
through 22 contain an IPv6 address. Bit 8 of octet 7 represents the most significant bit 
of the IPv6 address and bit 1 of octet 22 the least significant bit. 

If PDN type value indicates IPv4/IPv6, octet 6 contains the IPv6 Prefix Length. Octets 7 
through 22 contain an IPv6 address. Bit 8 of octet 7 represents the most significant bit 
of the IPv6 address and bit 1 of octet 22 the least significant bit. Octets 23 through 26 
contain an IPv4 address. Bit 8 of octet 23 represents the most significant bit of the IPv4 
address and bit 1 of octet 26 the least significant bit. 



8.1 5 Bearer Quality of Service (Bearer QoS) 



Editor's not; Bearer Quality of Service (Bearer QoS) is transferred via GTP tunnels. The sending entity copies the 
value part of the Bearer 1 QoS into the Value field of the Bearer QoS IE. 



Octets 

1 
2-3 

4 

5 

6-(n-i-4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 80 (decimal) 




Length = n (decimal) 


CR Spare Instance 


ARP 


Flow Ouality of Service Flow (Flow QoS) 



Figure 8.15-1 : Bearer Level Quality of Service (Bearer QoS) 

ARP shall be specified in 3GPP TS 36.413 [10] 
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8.1 6 Flow Quality of Service (Flow QoS) 



Flow Quality of Service (Flow QoS) is transferred via GTP tunnels. The sending entity copies the value part of the 
Flow QoS into the Value field of the Flow QoS IE. 



Octets 

1 

2-3 

4 

5 
6-10 
11-15 
16-20 
21-25 


Bits 
8 7 6 5 4 3 2 1 




Type = 81 (decimal) 




Length = n (decimal) 


CR Spare Instance 


Label (QCI) 


Maximum bit rate for uplink 


Maximum bit rate for downlink 




Guaranteed bit rate for uplink 




Guaranteed bit rate for downlink 




26-(n-i-4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.16-1 : Flow Quality of Service (Flow QoS) 

QCI, Maximum bit rate for uplink, Maximum bit rate for downlink. Guaranteed bit rate for uplink and Guaranteed bit 
rate for downlink shall be specified in 3GPP TS 36.413 [10]. 

Note: The encoding in 3GPP TS 24.301 is different from the encoding here. 



8.17 RAT Type 



RAT Type is coded as this is depicted in Figure 8.17-1. 



Octets 

1 

2-3 

4 

5 


Bits 
8 7 6 5 4 3 2 1 




Type = 82 (decimal) 




Length = 1 (decimal) 


CR Spare Instance 


RAT Type 


6-(n-i-4) 


These octet(s) is/are present only If explicitly specified 





Figure 8.17-1 : RAT Type 

Editor's note: RAT Type value range 1-255 is sufficient and extensions are not necessary. 

Table 8.17-1 : RAT Type values 



RAT Types 


Values (Decimal) 


<reserved> 





UTRAN 


1 


GERAN 


2 


WLAN 


3 


GAN 


4 


HSPA Evolution 


5 


EUTRAN 


6 


<spare> 


7-255 



Editor's note: Spare values 7-255 will be used for other RAT Type definitions (e.g. other non-3GPP accesses). 
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8.18 Serving Network 

Serving Network is coded as this is depicted in Figure 8.18-1. If MNC is 2 digits long, MNC digit 1 shall be set to 0. 

Editor's note: In the first release of GTPv2 spec (TS 29.274v8.0.0) n = 3. That is, the overall length of the IE is 6 
octets. In future releases of the spec additional octets may be specified. The legacy receiving entity 
simply ignores the unknown octets. 



Octets 

1 
2-3 
4 
5 
6 
7 
8-(n-i-4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 83 (decimal) 




Length = n (decimal) 


CR 1 Spare 


Instance 


MCC digit 1 


MCC digit 2 


MCCdigitS 


MNC digit 1 


MNC digit 2 


MNC digit 3 




These octet(s) is/are present only if explicitly specified 



Figure 8.18-1 : Serving Network 



8.19 Tunnel Endpoint Identifier for Control Plane (TEID-C) 

Tunnel Endpoint Identifier for Control Plane (TEID-C) is coded as this is depicted in Figure 8.19-1. 



Octets 

1 
2-3 

4 
5-8 


Bits 
8 7 6 5 4 3 2 1 




Type = 84 (decimal) 




Length = 4 (decimal) 


CR Spare Instance 


Tunnel Endpoint Identifier for Control Plane (TEID-C) 


9-(n-i-4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.19-1 : Tunnel Endpoint Identifier for Control Plane (TEID-C) 



8.19a Tunnel Endpoint Identifier for User Plane (TEID-U) 

Tunnel Endpoint Identifier for User Plane (TEID-U) is coded as this is depicted in Figure 8.19a. 



Octets 

1 
2-3 

4 
5-8 


Bits 
8 7 6 5 4 3 2 1 




Type = (decimal) 




Length = 4 (decimal) 


CR Spare Instance 


Tunnel Endpoint Identifier for User Plane (TEID-U) 



Figure 8.19a: Tunnel Endpoint Identifier for User Plane (TEID-U) 

8.19b Tunnel Endpoint Identifier for User Plane with EBI (TEID-U 
EBI) 

Tunnel Endpoint Identifier for User Plane with EBI (TEID-U EBI) is coded as this is depicted in Figure 8. 19b. 



Octets 

1 
2-3 

4 
5-(n-H4) 


Bits 
8 7 6 5 4 3 2 1 




Type = (decimal) 




Length = n (decimal) 


CR Spare Instance 


Tunnel Endpoint Identifier for User Plane with EBI 



Figure 8.19b: Tunnel Endpoint Identifier for User Plane with EBI (TEID-U EBI) 
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8.20 EPS Bearer Level Traffic Flow Template (Bearer TFT) 

EPS Bearer Level Traffic Flow Template (Bearer TFT) is transferred via GTP tunnels. The sending entity copies the 
value part of the EPS Bearer Level TFT into the Value field of the EPS Bearer Level TFT IE. 

Editor's note: EPS Bearer Level TFT will be defined in 3GPP TS 23.003 and its coding in TS 24.301. 

Editor's note: It is FFS whether it needs two separate IE types for EPS Bearer Level TFT and SDF Level TFT. 



Octets 

1 
2-3 

4 
5-(n-i-4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 85 (decimal) 




Length = n (decimal) 


CR Spare Instance 


EPS Bearer Level Traffic Flow Template (TFT) 



Figure 8.20-1 : EPS Bearer Level Traffic Flow Template (Bearer TFT) 



8.21 Traffic Aggregate Description (TAD) 

The Traffic Aggregate Description IE is coded as depicted in figure 8.21-1. The Traffic Aggregate Description is 
defined in 3GPP TS 24.008 [5]. 



Octets 

1 
2-3 

4 
5-(n-H4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 86 (Decimal) 




Length = n (decimal) 


CR Spare Instance 


Traffic Aggregate Description 



Figure 8.21-1 Traffic Aggregate Description 



8.22 User Locatiori Info (ULI) 

User Location Info (ULI) is coded as this is depicted in Figure 8.22-1. 



Octets 

1 

2-3 
4 
5 

x-(n-i-4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 87 (decimal) 




Length = n (decimal) 


CR 


Spare 


Instance 


Spare Spare Spare 


ECGI 


TAI 1 RAI 1 SAI 


CGI 


CGI 


SAI 


RAI 


TAI 


ECGI 



Figure 8.22-1 : User Location Info 

The flags ECGI, TAJ, RAI, SAI and CGI in octed 5 indicate if the corresponding fields are present in the IE or not. If 
one of these flags is set to "0", the corresponding field is not present at all. The respective identities are defined in 3GPP 
TS 23.003 [2]. 

Editor's Note: The definition of ECGI is missing in 3GPP TS 23.003 v8.1.0. It can be found in 3GPP TS 36.413 
v8.3.0, but it is expected that it will be moved to 23.003 in a future version. 

The following subclauses specify the coding of the different identities. 
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8.22.1 CGI field 

The coding of CGI (Cell Global Identifier) is depicted in Figure 8.22.1-1. If MNC is 2 digits long, MNC digit 1 shall be 
set to 0. 



Octets 

6 

7 

8 
9-10 
11-12 


Bits 
8 7 6 5 4 3 2 1 




MCC digit 1 


MCC digit 2 




IVICCdigitS 


MNC digit 1 


l\/INCdigit2 


MNC digit 3 


Location Area Code (LAC) 


Cell Identity (CI) 



Figure 8.22.1-1: CGI 

The Location Area Code (LAC) consists of 2 octets. Bit 8 of Octet 4 is the most significant bit and bit 1 of Octet 5 the 
least significant bit. The coding of the location area code is the responsibility of each administration. Coding using full 
hexadecimal representation shall be used. 

The Cell Identity (CI) consists of 2 octets. Bit 8 of Octet 6 is the most significant bit and bit 1 of Octet 7 the least 
significant bit. The coding of the cell identity is the responsibility of each administration. Coding using full hexadecimal 
representation shall be used. 

8.22.2 SAI field 

The coding of SAI (Service Area Identifier) is depicted in Figure 8.22.2-1. If MNC is 2 digits long, MNC digit 1 shall 
be set to 0. 



Octets 

6 

7 

8 
9-10 
11-12 


Bits 
8 7 6 5 4 3 2 1 




MCC digit 1 


MCC digit 2 




MCC digit 3 


MNC digit 1 


MNC digit 2 


MNC digit 3 


Location Area Code (LAC) 


Service Area Code (SAC) 



Figure 8.22.2-1: SAI 

The Location Area Code (LAC) consists of 2 octets. Bit 8 of Octet 4 is the most significant bit and bit 1 of Octet 5 the 
least significant bit. The coding of the location area code is the responsibility of each administration. Coding using full 
hexadecimal representation shall be used. 

The Service Area Code (SAC) consists of 2 octets. Bit 8 of Octet 6 is the most significant bit and bit 1 of Octet 7 the 
least significant bit. The SAC is defined by the operator. See 3GPP TS 23.003 [2] section 12.5 for more information. 

8.22.3 RAI field 

The coding of RAI (Routing Area Identity) is depicted in Figure 8.22.3-1. If MNC is 2 digits long, MNC digit 1 shall be 
set to 0. 



Octets 

6 

7 

8 
9-10 
11-12 


Bits 
8 7 6 5 4 3 2 1 




MCC digit 1 


MCC digit 2 




MCC digit 3 


MNC digit 1 


MNC digit 2 


MNC digit 3 


Location Area Code (LAC) 


Routing Area Code (RAC) 



Figure 8.22.3-1: RAI 

The Location Area Code (LAC) consists of 2 octets. Bit 8 of Octet 4 is the most significant bit and bit 1 of Octet 5 the 
least significant bit. The coding of the location area code is the responsibility of each administration. Coding using full 
hexadecimal representation shall be used. 
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The Routing Area Code (RAC) consists of 2 octets. Only Octet 6 contains the RAC. Octet 7 is coded as all I's 
(11 11 11 11). The RAC is defined by the operator. 

8.22.4 TAI field 

The coding of TAI (Tracking Area Identity) is depicted in Figure 8.22.4-1. If MNC is 2 digits long, MNC digit 1 shall 

be set to 0. 



Octets 

6 

7 

8 

9-10 


Bits 
8 7 6 5 4 3 2 1 




MCC digit 1 


MCC digit 2 




IVICCdigitS 


MNC digit 1 


l\/INCdigit2 


MNC digit 3 


Tracl<ing Area Code (TAG) 



Figure 8.22.4-1 : TAI 

The Tracking Area Code (TAC) consists of 2 octets. Bit 8 of Octet 4 is the most significant bit and bit 1 of Octet 5 the 
least significant bit. The coding of the tracking area code is the responsibility of each administration. Coding using full 
hexadecimal representation shall be used. 

8.22.5 ECGI field 

The coding of ECGI (E-UTRAN Cell Global Identifier) is depicted in Figure 8.22.5-1. If MNC is 2 digits long, MNC 
digit 1 shall be set to 0. 



Octets 

6 
7 
8 
9 
10-11 


Bits 
8 7 6 5 4 3 2 1 




MCC digit 1 


MCC digit 2 




MCC digit 3 


MNC digit 1 


MNC digit 2 


MNC digit 3 


Spare 


ECl 


ECl (E-UTRAN Cell Identifier) 



Figure 8.22.5-1: ECGI 

The E-UTRAN Cell Identifier (ECl) consists of 28 bits. Bit 4 of octet 4 is the most significant bit and bit 1 of Octet 7 
the least significant bit. The coding of the E-UTRAN cell identifier is the responsibility of each administration. Coding 
using full hexadecimal representation shall be used. 

8.23 Fully Qualified TEID (F-TEID) 

Fully Qualified Tunnel Endpoint Identifier (F-TEID) is coded as this is depicted in Figure 8.23-1. 



Octets 

1 

2-3 

4 

4 

5-8 

9 -(8-i-m) 

(9+m) - 

(8+p) 

(9+p)- (8+q)- 

(9+q) - (n+4) 


8 


Bits 
7 6 5 4 3 2 1 




Type = 88 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 


V4 1 


V6 1 EBIF 


Interface type 


TEID /GRE Key 


IPv4 address 


IPv6 address 


Spare | EPS Bearer ID (EBI) 


These 


octet(s) is/are present only if explicitly specified 



Figure 8.23-1 : Fully Qualified Tunnel Endpoint Identifier (F-TEID) 

where m=4*v4 , p=4*v4+16*v6 and q=4*v4+16*v6+EBIF. 
The following flags are coded within Octet 4: 
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Bit 8 - V4: If this bit is set to 1, then IPv4 address field exists in the F-TEID otherwise the IPv4 address field is 
not present at all. . 

Bit 7 - V6: If this bit is set to 1, then IPv6 address field exists in the F-TEID otherwise the IPv6 address field is 
not present at all. 

Bit 6 - EBIF: If this bit is set to 1, then EPS Bearer ID field and Spare exist in the F-TEID otherwise Spare and 
EPS Bearer ID field are not present at all. 

Bit 5 to Bit 1 - Interface Type: This 5 bit wide integer can take the following values representing interface type 
and endpoint:. 

Sl-UeNBGTP-U interface 

1 S 1 -U SGW GTP-U interface 

2 S 1 2 RNC GTP-U interface 

3 S 1 2 SGW GTP-U interface 

4 S5/S8 SGW GTP-U interface 

5 S5/S8 PGW GTP-U interface 

6 S5/S8 SGW GTP-C interface 

7 S5/S8 PGW GTP-C interface 

8 S5/S8 SGW PMIPv6 interface (the 32 bit GRE key is encoded in 32 bit TEID field and since alternate 
CoA is not used the control plane and user plane addresses are the same for PMIPv6) 

9 S5/S8 PGW PMIPv6 interface (the 32 bit GRE key is encoded in 32 bit TEID field and the control plane 
and user plane addresses are the same for PMIPV6) 

10 Sll MME GTP-C interface 

11 S 11/S4 SGW GTP-C interface 

12 S 10 MME GTP-C interface 

13 S3 MME GTP-C interface 

14 S3 SGSN GTP-C interface 

15 S4 SGSN GTP-U interface 

16 S4 SGW GTP-U interface 

17 S4 SGSN GTP-C interface 

18 S16 SGSN GTP-C interface 

Other values of "Interface Type" are reserved for future use 

Editor's note: If S4 is decided to be GTPv2, then another bit is needed to indicate that the F-TEID belongs to Rel8 
SGSN. In such case one more octet may be added to the IE. 
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8.24 TMSI 

The TMSI, unambiguously associated with a given UE and Location area, is given by: 



Octets 

1 

2-3 

4 

5-(rn-4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 89 (decimal) 




Length = n (decimal) 


CR Spare Instance 


TMSI 
The TMSI is defined in 3GPP TS 23.003 [2]. 



Figure 8.xx-1 : TMSI 



8.25 Global CN-ld 



The Global CN-Id is coded as this is depicted in Figure 8.25-1. 



Octets 

1 
2-3 

4 
5 
6 

7 
8-(n-^4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 90 (decimal) 




Length = n (decimal) 


CR 1 Spare 


Instance 


MCCdigit2 


MCC digit 1 


MNCdigitS 


MCCdigitS 


MNCdigit2 


MNC digit 1 


CN-ld 
The CN-ld is defined in 3GPP TS 23.003 [2]. 



Figure 8.25-1 : Global CN-ld 

If an Administration decides to include only two digits in the MNC, then bits 5 to 8 of octet 6 are coded as "1111". 

8.26 Legacy Quality of Service (QoS) 

Legacy Quality of Service (QoS) is transferred via GTP tunnels. The sending entity copies the value part of the Legacy 
QoS into the Value field of the Legacy QoS IE. 

Legacy Quality of Service (QoS) in the Figure 8.26-1 is coded according to 3GPP TS 24.008 [5]. 



Octets 

1 
2-3 

4 
5-(n-H4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 91 (decimal) 




Length = n (decimal) 


CR Spare Instance 


Legacy Quality of Service (QoS) 



Figure 8.26-1 : Legacy Quality of Service (QoS) 
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8.27 S1 03 PDN Data Forwarding Info (S1 03PDF) 

The PDSN Address and GRE Key identify a GRE Tunnel towards a PDSN over S 103 interface for a specific PDN 
connection of the UE. The EPS Bearer IDs specify the EPS Bearers which require data forwarding that belonging to this 
PDN connection. The number of EPS bearer Ids included is specified by the value of EPS Bearer ID Number. 

The spare bits indicate unused bits, which shall be set to by the sending side and which shall not be evaluated by the 
receiving side. 



Octets 


Bits 
8 7 6 5 4 3 2 1 




1 

2-3 

4 

5 

6-(m+5) 

{m+6)-(m+9) 

(m+10) 

(m+11)- 

(m+10+n) 


Type = 92 (decimal) 




Length = n (decimal) 


CR Spare Instance 


PDSN Address for forwarding Length 


PDSN Address for forwarding [4..1 6] 


GRE Key 


EPS Bearer ID Number = n 


Spare 


Spare 


Spare 


Spare 


EPS Bearer ID 



Figure 8.27-1 : SI 03 PDN Data Forwarding Info 

Editor's Notes; It is FFS whether it is needed to include PDN Identifer in this IE 

8.28 S1 -U Data Forwarding (S1 UDF) 

The Serving GW Address and Serving GW Sl-U TEID consisit the Sl-U Tunnel information allocated by the Serving 
GW for an EPS Bearer identified by the EPS Bearer ID which requires data forwarding during active handover from E- 
UTRAN Access to cdma2000 HRPD Access. 

The spare bits indicate unused bits, which shall be set to by the sending side and which shall not be evaluated by the 
receiving side. 



Octets 

1 

2-3 

4 

5 

6 

7-(m+6) 
(m+7)- 
(m+10) 


Bits 
8 7 6 5 4 3 2 1 




Type = 93 (decimal) 




Length = n (decimal) 


CR 


Spare 


Instance 


Spare Spare Spare 


Spare 


EPS Bearer ID 


Serving GW Address Length 


Serving GW Address [4. .16] 


Serving GW Sl-U TEID 



Figure 8.28-1 : Sl-U Data Forwarding Info 
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8.29 Delay Value 

Delay Value is coded as this is depicted in Figure 8.29-1. 



Octets 

1 

2-3 

4 

5 

6-(n-i-4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 94 (decimal) 




Length = n (decimal) 


CR Spare Instance 


Delay Value in integer multiples of 50 millisecs, or zero 


These octet(s) is/are present only if explicitly specified 



Figure 8.29-1 : Delay Value 

Delay Value is set to zero in order to clear a previously set delay condition. 

8.30 Bearer ID List 

Bearer ID List is coded as this is depicted in Figure 9.30-1. 



Octets 

1 
2-3 
4 
5 
6 

7 

5-Hm 
6+m-(n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 95 (decimal) 




Length = n (decimal) 


CR Spare Instance 


m= number of bearer ID 


Spare 


first Bearer ID 


Spare 


second Bearer ID 






Spare 


m'th Bearer ID 


These octet(s) is/are present only if explicitly specified 



Figure 8.30-1 : Bearer ID List 
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8.31 Bearer Context 

Bearer Context is a grouped IE containing a number of other lEs. Which of those IBs are mandatory, optional or 
conditional and the conditions that apply are GTP message specific, and described in the corresponding subclause under 
clause 7. 

Bearer Context is normally repeated within a message with exactly the same Type and Instance values to represent a list 
of Bearer Contexts. 

Bearer Context is coded as this is depicted in Table 8.31-1. 

Table 8.31-1 : Bearer Context 



Bearer Context IE Type = 96 (decimal) 




Length = n (decimal) 




Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Instance 


EPS Bearer ID 






1 


EBI 




Cause 




Used only in response messages 

Indicates if the bearer handling was successful, and if not, 

gives information on the reason. 


1 


Cause 




NSAPI 




Sent in case of 3G SGSN to MME combined hard 
handover and SRNS relocation procedure 


1 


NSAPI 




ULTFT 




Used only on request messages 
Used only for PIVIIP 


1 


Bearer TFT 




DLTFT 




Used only on request messages 


1 


Bearer TFT 




S1 eNodeB F-TEID 






1 


F-TEID 




S1 SGW F-TEID 






1 


F-TEID 




S4-U SGSN F-TEID 




Qnly applicable if S4 is used 


1 


F-TEID 




S4-U SGW F-TEID 




Qnly applicable if S4 is used 


1 


F-TEID 




S5/8-U SGW F-TEID 






1 


F-TEID 




S5/8-U PGW F-TEID 






1 


F-TEID 




S12RNC F-TEID 




Only applicable if S12 is used 


1 


F-TEID 




S12 SGW F-TEID 




Qnly applicable if S12 is used 


1 


F-TEID 




Bearer Level QoS 






1 


Bearer 
QoS 




Legacy QoS 






1 


Legacy 
QoS 




Charging 
Characteristics 




Used only in direction IVIME -> SGW -> PGW 


1 


Charging 

Characteris 

tics 




Charging Id 




Used only in direction PGW -> SGW -> IVIME 


1 


Charging Id 




Prohibit Payload 
Compression 




Used only in direction PGW -> SGW -> IVIME 


1 







8.32 S101 IP Address 

SIOl IP address shall be coded as depicted in Figure 8.32-1. It contains the HRPD access node IP address. The Length 
field may have only two values (4 or 16) that determine if the Value field contains IPv4 or IPv6 address. 



Octets 

1 
2-3 

4 
5-(n-H4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 97 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




IPv4 or IPv6 Address 



Figure 8.32-1 : SI 01 IP address 
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8.33 S102 IP Address 

S102 IP address shall be coded as depicted in Figure 8.33-1. It contains the IxCS IWS IP address. The Length field may 
have only two values (4 or 16) that determine if the Value field contains IPv4 or IPv6 address. 



Octets 

1 

2-3 

4 

5-(n+4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 98 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




IPv4 or IPv6 Address 



Figure 8.33-1 : SI 02 IP address 



8.34 Charging ID 



The Charging ID is a unique four-octet value generated by the PDN GW when a dedicated bearer is activated. A 
Charging ID is generated for each dedicated bearer. The Charging ID value is reserved and shall not be assigned by 
the PDN GW. 



Octets 

1 
2-3 

4 
5-8 

9-(n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 99 (decimal) 




Length = 4 (decimal) 


CR Spare Instance 


Charging ID value 


These OGtet(s) is/are present only if explicitly specified 



Figure 8.34-1 : Charging ID 



8.35 Charging Characteristics 



The charging characteristics information element is defined in 3GPP TS 32.251 [8] and is a way of informing both the 
SGW and PGW of the rules for producing charging information based on operator configured triggers. For the encoding 
of this information element see 3GPP TS 32.298 [9]. 



Octets 

1 
2-3 

4 
5-6 

7-(n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 100 (decimal) 




Length = 2 (decimal) 


CR Spare Instance 


Charging Characteristics value 


These octet(s) is/are present only if explicitly specified 



Figure 8.35-1: Charging Characteristics 
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8.36 Trace Information 

Trace Information is coded as this is depicted in Figure 8.36-1. See [18] for details on trace related information. 



Octets 

1 
2-3 

4 

5 
6-v 

v+^ 

(v-h2) - X 

x+1 
(x+2)-y 

y+1 

(y+2)-z 

(z+1)-(n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 101 (decimal) 




Length = n (decimal) 


CR Spare Instance 


Trace Reference Length 


Trace Reference Value 


Trace Id Length 


Trace Id Value 


Trigger Id Length 


Trigger Id Value 


OIVIC Identity Length 


OMC Identity Value 


These octet(s) is/are present only if explicitly specified 



Figure 8.36-1 : Trace Information 



8.37 Bearer Flags 

Bearer Flags is coded as this is depicted in Figure 8.37-1. 



Octets 

1 

2-3 

4 

5 

6-(n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 102 (decimal) 




Length = n (decimal) 


CR 


Spare 


Instance 


Spare Spare Spare 


Spare 


Spare Spare Spare PPC 


These octet(s) is/are present only if explicitly specified 



Figure 8.37-1 : Bearer Flags 



The following bits within Octet 5 indicate: 



Bit 1 - PPC (Prohibit Payload Compression): This flag is used to determine whether an SGSN should attempt to 
compress the payload of user data when the users asks for it to be compressed (PPC = 0), or not (PPC =1). 



8.38 Paging Cause 



Paging Cause is transferred from the SGW to MME across SI 1 so it can then be passed to the eNodeB over SlAP in the 
Paging message as specified in 3GPP TS 36.413 [10]. 

The Paging Cause is coded as shown in Figure 8.38-1. 



Octets 

1 
2-3 

4 
5-(n+4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 103 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




Paging Cause value 



Figure 8.38-1 : Paging Cause 
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8.39 PDN Type 

The PDN Type is coded as depicted in Figure 8.39-1. 



Octets 

1 

2-3 

4 

5 


Bits 
8 7 6 5 4 3 2 1 




Type = 104 (decimal) 




Length = n (decimal) 


CR Spare Instance 


Spare | PDN Type 


6-(n-i-4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.39-1 : PDN Type 
Table 8.39-1 : PDN Type 



PDN type value (octet 4) 

Bits 

3 2 1 

1 IPv4 

1 IPv6 

1 1 IPv4/IPv6 

Bits 8-4 of octet 4 are spare and shall be coded as zero. 



8.40 Procedure Transaction ID (PTI) 

Procedure Transaction Id is coded as this is depicted in Figure 8.40-1. 



Octets 

1 
2-3 

4 
5 


Bits 
8 7 6 5 4 3 2 1 




Type = 105 (decimal) 




Length = n (decimal) 


CR Spare Instance 


Procedure Transaction ID 


6-(n-i-4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.40-1 : Procedure Transaction ID 



8.41 DRX Parameter 



DRX Parameter indicates whether the UE use DRX mode or not, this parameter is coded as this is depicted in Figure 
8.41-1. 



Octets 

1 

2-3 

4 

5-(n-^4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 106 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




DRX Parameter 



Figure 8.41-1 : DRX Parameter 
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8.42 UE Network Capability 

UE Network Capability is coded as this is depicted in Figure 8.42-1. 



Octets 

1 

2-3 

4 

5-(rn-4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 107 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




UE Network Capability 



Figure 8.42-1 : UE Network Capability 

8.43 IVIIVI Context 

The MM Context information element contains the Mobility Management, UE security parameters that are necessary to 
transfer over S3/S16/S10 interface. 

Security Mode indicates the type of security keys (GSM/UMTS/EPS) and Authentication Vectors (quadruplets 
/quintuplets/triplets) that are passed to the new MME/SGSN. 

Used Cipher indicates the GSM ciphering algorithm that is in use. 

Used NAS Cipher indicates the EPS ciphering algorithm that is in use. 

As depict in Figure 8.43-1, the GSM Key, Used Cipher and Authentication Triplets that are unused in the old SGSN 
shall be transmitted to the new SGSN for the GSM subscribers. 



Octets 

1 
2-3 

4 
5-(n-h4) 


Bits 
8 7 6 5 4 3 2 1 




Type 




Length = n (decimal) 


CR Spare Instance 


These octet(s) is/are present only if explicitly specified 



Octets 


Bits 
8 7 6 5 4 3 2 1 




1 


Type = 109 (decimal) 




2-3 


Length = n (decimal) 


4 


CR 


Spare Instance 


5 


Security Mode 


Spare 1 1 | CKSN 


6 


Number of Triplet 


Sparelim 


7 


Sparelim | Used Cipher 


8-15 


Kc 


16-h 


Authentication Triplet [0..4] 


(h-Hl)-(h+5) 


DRX parameter 


(h+6)-m 


UE Network Capability 


(m+1)-(n+4) 


IVIE Identity 



Figure 8.43-1 : GSM Key and Triplets 

As depict in Figure 8.43-2, the UMTS Key, Used Cipher and Authentication Quintuplets that are unused in the old 
SGSN shall be transmitted to the new SGSN when the UMTS subscriber is attached to a GSM BSS in the old system, in 
case the user has a ME capable of UMTS AKA. 
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Octets 

1 

2-3 
4 
5 


Bits 
8 7 6 5 4 3 2 1 




Type = 110 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 


Security IVIode 


Spare 1 1 | CKSN/KSI 


6 


Number of 
Quintuplets 


Spare 11111 




7 


Spare 11111 | Used Cipher 




8-23 


CK 




24-39 


IK 




40-h 


Authentication Quintuplet [0..4] 




(h-i-1)-(hn-5) 


DRX parameter 




(h-H6)-m 


UE Network Capability 




(rTn-1)-(rn-4) 


ME Identity 





Figure 8.43-2: UMTS Key, Used Cipher and Quintuplets 

As depict in Figure 8.43-3, the GSM Key, Used Cipher and Authentication Quintuplets that are unused in the old SGSN 
shall be transmitted to the new SGSN when the UMTS subscriber is attached to a GSM BSS in the old system, in case 
the user has a ME no capable of UMTS AKA. 



Octets 

1 

2-3 

4 

5 


Bits 
8 7 6 5 4 3 2 1 




Type = 111 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 


Security IVIode 


Spare 1 1 | CKSN/KSI 


6 


Number of 
Quintuplets 


Spare 11111 




7 


Spare 11111 | Used Cipher 




8-15 


Kc 




16-h 


Authentication Quintuplets [0..4] 




(h+1)-(h-i-5) 


DRX parameter 




(h-H6)-m 


UE Network Capability 




(m-Hl)-(n-H4) 


IVIE Identity 





Figure 8.43-3: GSM Key, Used Cipher and Quintuplets 

As depict in Figure 8.43-4, the UMTS Key, KSI and unused Authentication Quintuplets in the old SGSN shall be 
transmitted to the new SGSN/MME when the UMTS subscriber is attached to UTRAN in the old system. 



Octets 

1 

2-3 

4 

5 


Bits 
8 7 6 5 4 3 2 1 




Type = 112 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 


Security IVIode 


Spare 11 | KSI 


6 


Number of 
Quintuplets 


Spare 11111 




7 


Spare 11111 




8-23 


CK 




24-39 


IK 




40-h 


Authentication Quintuplet [0..4] 




(h-i-1)-(h-i-5) 


DRX parameter 




(h-H6)-m 


UE Network Capability 




(m-i-1)-(n-H4) 


IVIE Identity 





Figure 8.43-4: UMTS Key and Quintuplets 

As depict in Figure 8.43-5, the EPS Security Context, unused Authentication Quadruplets in the old MME shall be 
transmitted to the new MME. And the Authentication Quintuplets may also be transmitted to the new MME if the old 
MME has the Authentication Quintuplets for this UE. 
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Octets 

1 

2-3 

4 

5 


Bits 
8 7 6 5 4 3 2 1 




Type= 113 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 


Security IVIode 


Spare 11 KSIasme 


6 


Number of 
Quintuplets 


Number of 
Quadruplet 


Spare 1 1 




7 


Spare 
1 


Used NAS integrity 
protection algorithm 


Used NAS Cipher 




8-10 


NAS Downlink Count 




11-13 


NAS Uplink Count 




14-45 


Kasme 




46-g 


Authentication Quadruplet[0..4] 




(g+1)-h 


Authentication Quintuplet [0..4] 




(h+1)-(h-i-5) 
(hn-6)-m 


DRX parameter 




UE Network Capability 


(m-i-1)-(rn-4) 


IVIE Identity 





Figure 8.43-5: EPS Security Context, Quadruplets and Quintuplets 

NAS integrity protection algorithm shall be specified in 3GPP TS 24.301 [23]. 

As depict in Figure 8.43-6, if the old MME has Authentication Quintuplets for this UE, the old MME will derive CK' 
and IK' from Kasme and transmit the CK', IK', KSIasme and Authentication Quintuplets to the new SGSN, the 
Authentication Quadruplets may also be transmitted to the new SGSN. 

Editor's Notes: the old SGSN/MME may delivery both Authentication Quadruplets and Authentication Quintuplets 
it holds to the peer combo node to optimize the procedure, the details need more clarification 



Octets 

1 

2-3 

4 

5 


Bits 
8 7 6 5 4 3 2 1 




Type = 114 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 


Security IVIode 


Spare 11 KSIasme 


6 


Number of 
Quintuplets 


Number of 
Quadruplet 


Spare 1 1 




7 


Spare 




8-23 


CK 




24-39 


IK 




40-g 


Authentication Quadruplet[0..4] 




(g+1)-h 


Authentication Quintuplet [0..4] 




(h+1)-(h-H5) 


DRX parameter 




{m+^)-{n+4) 


UE Network Capability 




IVIE Identity 



Figure 8.43-6: UMTS Key, Quadruplets and Quintuplets 
Table 8.43-1 : Security Mode Values 



Security Type 


Value (Decimal) 


GSM Key and Triplets 





UMTS Key, Used Cipher and Quintuplets 


1 


GSM Key, Used Cipher and Quintuplets 


2 


UMTS Key and Quintuplets 


3 


EPS Security Context, Quadruplets and Quintuplets 


4 


UMTS Key, Quadruplets and Quintuplets 


5 
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Table 8.43-2: Used NAS Cipher Values 



Cipher Algorithm 


Value (Decimal) 


No ciphering 





128-EEA1 


1 


128-EEA2 


2 


Table 8.43-3: Used Cipher Values 


Cipher Algorithm 


Value (Decimal) 


No cipliering 





GEA/1 


1 


GEA/2 


2 


GEA/3 


3 


GEA/4 


4 


GEA/5 


5 


GEA/6 


6 


GEA/7 


7 
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8.44 PDN Connection 

The PDN connection is coded as this is depicted in Table 8.47-1. 



Table 8.44-1 : PDN Connection 







PDN Connection IE Type =115 (decimal) 












Length = n (decimal) 








Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Instance 


APN 


M 


None 


1 


APN 




IPv4 Address 


C 


None if no IPv4 Address assigned 


1 


IP Address 




IPv6 Address 


C 


None if no IPv6 Address assigned 


1 


IP Address 




SGWS11/S4IP 
Address andTEIDfor 
Control Plane 


M 




1 


F-TEID 




PGW S5/S8 IP 
Address and TEID for 
Control Plane 


C 


Only Included for GTP based S5/S8 


1 


F-TEID 




LMA Address 


C 


Only included for PMIP based S5/S8 


1 


LMA 
Address 




GRE Key 


c 


Only included for PMIP based S5/S8 


1 


GRE Key 




Bearer Contexts 


c 


Several lEs with this type and instance values may be 
included as necessary to represent a list of Bearers. 


1 


Bearer 
Context 





The PDN Connection IE is a grouped IE. The PDN Connection IE is normally repeated within a message with exactly 
the same Type and Instance values to represent a list. 

The Bearer Context is coded as this is depicted in Table 8.44-2. 

Table 8.44-2: Bearer Context in PDN Connection 







Bearer Context IE Type = 96 (decimal) 












Length = n (decimal) 








Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Instance 


EPS Bearer ID 


M 




1 


EBI 




ULTFT 







1 


Bearer TFT 




DLTFT 







1 


Bearer TFT 




SGWS1/S4/S12IP 
Address and TEID for 
user plane 


c 




1 


F-TEID 




PGW S5/S8 IP 
Address andTEIDfor 
user plane 


c 


Only included for GTP based S5/S8 


1 


F-TEID 




Bearer Level QoS 


M 




1 


Bearer 
QoS 




Transaction Identifier 


M 




1 


Tl 




Charging 
characteristics 







1 


Charging 

characterist 

ics 




Container 





Packet Flow ID , Radio Priority, SAPI, PS Handover XID 
Parameters may be included 


1 


Container 
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8.45 GRE Key 



The GRE Key is coded as this is depicted in Figure 8.45-1. 



Octets 

1 

2-3 

4 

5-{n-^4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 116 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




GRE Key 



Figure 8.45-1 : GRE Key 



8.46 PDU Numbers 

The PDU Numbers information element contains the sequence number status corresponding to a Bearer context in the 
old SGSN. This information element shall be sent only when acknowledged peer-to-peer LLC operation is used for the 
Bearer context or when the "delivery order" QoS attribute is set in the Bearer context QoS profile. 

NSAPl identifies the Bearer context for which the PDU Number IE is intended. 

DL GTP-U Sequence Number is the number for the next downlink GTP-U T-PDU to be sent to the UE when "delivery 
order" is set. 

UL GTP-U Sequence Number is the number for the next uplink GTP-U T-PDU to be tunnelled to the S-GW when 
"delivery order" is set. 

The Send N-PDU Number is used only when acknowledged peer-to-peer LLC operation is used for the Bearer context. 
Send N-PDU Number is the N-PDU number to be assigned by SNDCP to the next down link N-PDU received from the 
S-GW. 

The Receive N-PDU Number is used only when acknowledged peer-to-peer LLC operation is used for the Bearer 
context. The Receive N-PDU Number is the N-PDU number expected by SNDCP from the next up link N-PDU to be 
received from the UE. 

The PDU Number IE will be repeated for each Bearer Context for which this IE is required. 

PDU Numbers IE is coded as this is depicted in Figure 8.46-1. 



Octets 

1 

2-3 

4 

5 

6-7 

8-9 

10-11 

12-13 

14-(n+4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 108 (decimal) 




Length = n (decimal) 


CR 1 Spare 


Instance 


Spare(0 0) 


NSAPl 


DL GTP-U Sequence Number 


UL GTP-U Sequence Number 


Send N-PDU Number 


Receive N-PDU Number 


These octet(s) is/are present only if explicitly specified 



Figure 8.46-1: PDU Numbers 
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8.47 EPS Bearer Contexts Prioritization (Contexts Prioritization) 

The EPS Bearer Contexts Prioritization information element is used by the old SGSN/MME to inform the new 
SGSN/MME that prioritization of the EPS Bearer Contexts has been applied. When the information element is 
included, the length is set to zero. 



Octets 

1 
2-3 

4 
5-(rn-4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 118 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 







Figure 8.47-1 : EPS Bearer Contexts Prioritization (Contexts Prioritization) 



8.48 LIVIA IP Address 

LMA IP address shall be coded as depicted in Figure 8.48-1. It contains the PDN GW IP address for PMIP -based S5/S8 
interface. The Length field may have only two values (4 or 16) that determine if the Value field contains IPv4 or IPv6 
address. 



Octets 

1 

2-3 

4 

5-(n-H4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 119 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




IPv4 or IPv6 Address 



Figure 8.48-1 : LIVIA IP Address 



8.49 Packet TIVISI (P-TIVISI) 

The P-TMSI, unambiguously associated with a given UE and routeing area, is given by: 



Octets 

1 

2-3 

4 

5-(n-H4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 120 (decimal) 




Length = n (decimal) 


CR Spare Instance 


Packet TMSI (P-TMSI) 
The P-TMSI is defined in 3GPP TS 23.003 [2]. 



Figure 8.49-1 : Packet TMSI (P-TMSI) 



8.50 P-TIVISI Signature 



The P-TMSI Signature information element is provided by the UE in the Routeing Area Update Request and Attach 
Request messages to the SGSN, or is provided by the MME that is mapped from GUTI in the Identification Request and 
Context Request messages to the old SGSN for identification checking purposes. The content and the coding of the P- 
TMSI Signature information element are defined in 3GPP TS 24.008 [5]. 



Octets 

1 
2-3 

4 
5-(n-H4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 121 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




P-TMSI Signature 



Figure 8.50-1 : P-TMSI Signature 
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8.51 Hop Counter 



Where Intra Domain Connection of RAN Nodes to Multiple CN Node is applied, the Hop Counter may be used to 
prevent endless loops when relaying Identification Request messages and Context Request messages. The maximum 
value is operator specific and shall not be lower than 1 . 



Octets 

1 

2-3 

4 

4 

5-(n-i-4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 122 (decimal) 




Length = n (decimal) 


CR Spare Instance 


Hop Counter 


These octet(s) is/are present only if explicitly specified 



Figure 8.51-1 : Hop Counter 



8.52 Authentication Quintuplet 



An Authentication Quintuplet consists of a Random string (RAND), an Expected user response (XRES), a Cipher key 
(CK), an Integrity key (IK), an Authentication token (AUTN) (see 3GPP TS 33.102 [11]). 



Octets 

1 
2-3 

4 

5-20 
21 

22-m 
(m+1)- 
(m-i-16) 
(m+-\7)- 
(m-H32) 

m-i-33 
(m-H34)- 

(n+4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 123 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




RAND 


XRES Length 


XRES 


CK 


IK 


AUTN Length 


AUTN 



Figure 8.52-1 : Authentication Quintuplet 



8.53 Authentication Quadruplet 



An Authentication Quadruplet consists of a Random string (RAND), an Expected user response (XRES), an 
Authentication token (AUTN), a Key of Access Security Management Entity (Kasme) (see 3GPP TS 33.102 [11] and 
TS 33.401 [12]). 



Octets 

1 

2-3 

4 

5-20 

21 

22-m 

m-i-1 

(m-i-1)-(n-29) 

(n-28)-(n-H4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 124 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




RAND 


XRES Length 


XRES 


AUTN Length 


AUTN 


Kasme 



Figure 8.53-1 : Authentication Quadruplet 
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8.54 Complete Request Message 

The Complete Request Message is coded as this is depicted in Figure 8.54-1. 



Octets 

1 

2-3 

4 

5 

6-(rn-4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 125 (decimal) 




Length = n (decimal) 


CR Spare Instance 


Complete Request IVIessage Type 


Complete Request Message 



Figure 8.54-1 : Complete Request Message 

Complete Request Message type values are specified in Table 8.54-1. 

Table 8.54-1 : Complete Request Message type values and their meanings 



Location Types 


Values (Decimal) 


Complete Attach Request IVIessage 





Complete TAU Request IVIessage 


1 


<spare> 


2-255 



8.55 GUTI 



The GUTI is coded as this is depicted in Figure 8.55-1. 



Octets 

1 
2-3 

4 
5 
6 

7 

8-9 

10 

11-(n-i-4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 126 (decimal) 




Length = n (decimal) 


CR 1 Spare 


Instance 


MCC digit 2 


MCC digiti 


MNC digits 


MCC digits 


MNC digit2 


MNC digiti 


MME Group ID 


MME Code 


M-TMSI 



Figure 8.55-1: GUTI 

If an Administration decides to include only two digits in the MNC, then bits 5 to 8 of octet 3 are coded as " 1 1 11 " . 
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8.56 Fully Qualified Container (F-Container) 

Fully Qualified Container (F-TEID) is coded as this is depicted in Figure 8.56-1. 



8 


7 


Bits 
6 5 4 3 2 1 


Type = 127 (decimal) 


Length = n (decimal) 




CR 


Spare 


Instance 




Spare 1 


111 


Container Type 


F-Container field 



Octets 

1 
2-3 

4 

5 

6-(n-i-4) 

Figure 8.56-1: Full Qualified Container(F-Container) 

The Container Type is coded as below : 

If this field is set to 1, then the F-Container field present the UTRAN transparent container. 

If this field is set to 2, then the F-Container field present the BSS container. 

If this field is set to 3, then the F-Container field present the E-UTRAN transparent container. 

8.57 Fully Qualified Cause (F-Cause) 

Fully Qualified Cause (F- Cause) is coded as this is depicted in Figure 8.57-1. 



Octets 

1 
2-3 

4 
5-(n-H4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 128 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




F-Cause field 



Figure 8.57-1 : Full Qualified Cause (F-Cause) 



8.58 Selected PLIVIN ID 

The Selected PLMN ID IE contains the core network operator selected for tne UE in a shared network. Octets 4-6 shall 
be encoded as the content part of the 'Selected PLMN Identity' parameter in 3GPP TS 36.413 [10]. 



Octets 

1 

2-3 

4 

5-(n-H4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 129 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




Selected PLMN ID 



Figure 8.58-1 : Selected PLMN ID 
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8.59 Target Identification 



The Target Identification information element contains the identification of a target RNC or a target eNodeB. 



Octets 

1 

2-3 

4 

5 

6-(n-i-4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 130 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




Target Type 


Target ID 



Figure 8.59-1 : Target Identification 

Target type values are specified in Table 8.59-1. 

Table 8.59-1 : Target type values and their meanings 



Location Types 


Values (Decimal) 


RNC ID 





eNodeB ID 


1 


<spare> 


2-255 



8.60 NSAPI 

The NSAPI information element contains an NSAPI identifying a PDP Context. 

The spare bits x indicate unused bits, which shall be set to by the sending side, and the sending side shall not evaluate 
them. 



Octets 

1 
2-3 

4 
5 


Bits 
8 7 6 5 4 3 2 1 




Type = 132 (decimal) 




Length = n (decimal) 


CR 1 Spare 


Instance 


Spareim 


NSAPI 


6-(n-i-4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.60-1 : NSAPI 



8.61 Packet Flow ID 

The Packet Flow Id information element contains the packet flow identifier assigned to a PDP context as identified by 
NSAPI. 

The spare bits x indicate unused bits, which shall be set to by the sending side and which shall not be evaluated by the 
receiving side. 



Octets 

1 

2-3 

4 

5 

6-(n-i-4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = 133 (decimal) 




Length = n (decimal) 


CR 1 Spare 


Instance 


Spareim 


NSAPI 


Packet Flow ID 



Figure 8.61-1 : Packet Flow ID 
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8.62 RAB Context 



The RAB context information element contains sequence number status for one RAB in RNC, which corresponds to 
one PDF context. The RAB contexts are transferred between the RNCs via the SGSNs at inter SGSN hard handover. 

NSAPI identifies the PDF context and the associated RAB for which the RAB context IE is intended. 

DL GTF-U Sequence Number is the number for the next downlink GTP-U T-PDU to be sent to the UE. 

UL GTP-U Sequence Number is the number for the next uplink GTP-U T-PDU to be tunnelled to the SGW. 

DL PDCP Sequence Number is the number for the next downlink PDCP-PDU to be sent to the UE. 

UL PDCP Sequence Number is the number for the next uplink PDCP-PDU to be received from the UE. 

Table 8.62-1 : RAB Context 







RAB ContextlE Type = 134 (decimal) 












Length = n (decimal) 








Information 
elements 


P 


Condition / Comment 


CR 


IE Type 


Instance 


NSAPI 





Shall be included if the source node is a RNC 








DL GTP-U Sequence 
Number 





None 








UL GTP-U Sequence 
Number 





None 








DL PDCP Sequence 
Number 





None 








UL PDCP Sequence 
Number 





None 









The RAB Context is a Grouped IE. The RAB Context IE is normally repeated within a message with exactly the same 
Type and Instance to represent a list. 

8.63 Source RNC PDCP context info 

The purpose of the Source RNC PDCP context info IE is to transfer RNC PDCP context information from a source 
RNC to a target RNC during an SRNS relocation. 



Octets 

1 
2-3 

4 
5-(n-H4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 135 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




RRC Container 



Figure 8.63-1 : Source RNC PDCP context info 



8.64 UDP Source Port Number 

UDP Source Port Number is coded as this is depicted in Figure 8.64-1. 



Octets 

1 
2-3 

4 
5-6 

7-(n-i-4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 136 (decimal) 




Length = 2 (decimal) 


CR Spare Instance 


UDP Source Port Number 


These octet(s) is/are present only if explicitly specified 



Figure 8.64-1 : UDP Source Port Number 
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8.65 APN Restriction 

The APN Restriction information element contains an unsigned integer value indicating the level of restriction imposed 
on EPS Bearer Contexts created to the associated APN. 

The APN Restriction IE is coded as depicted in Figure 8.65-1: 



Octets 

1 
2-3 

4 


Bits 
8 7 6 5 4 3 2 1 




Type = 137 (Decimal) 




Length = n (decimal) 


CR Spare Instance 


Restriction Type value 


6-(n-i-4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.65-1 : APN Restriction Type Information Element 

An APN Restriction value may be configured for each APN in the PGW. It is used to determine, on a per UE basis, 
whether it is allowed to establish EPS bearers to other APNs. 

Table 8.65-1 : Valid Combinations of APN Restriction 



Maximum 

APN 
Restriction 

Value 


Type of APN 


Application Example 


APN Restriction Value allowed to be 
established 





No Existing Contexts or Restriction 


All 


1 


Public-1 


MMS 


1, 2, 3 


2 


Public-2 


Internet 


1,2 


3 


Private-1 


Corporate (e.g. who use 
MMS) 


1 


4 


Private-2 


Corporate (e.g. who do not 
use MMS) 


None 



Editor's Note: The actual application examples and combination of APN Restriction for EPS is FFS. 

8.66 Selection IVIode 

The Selection mode information element indicates the origin of the APN in the message. 



Octets 

1 

2-3 

4 

5 


Bits 
8 7 6 5 4 3 2 1 




Type = 138 (Decimal) 




Length = n (decimal) 


CR 


Spare 


Instance 


1 


1 


1 


1 


1 


1 


1 


Selec. 
Mode 


6-(n-i-4) 


These octet(s) is/are present only if explicitly specified 





Figure 8.66-1 : Selection Mode Information Element 



Table 8.66-1 : Selection Mode Values 



Selection mode value 


Value (Decimal) 


MS or network provided APN, subscribed verified 





MS provided APN, subscription not verified 


1 


Network provided APN, subscription not verified 


2 


For future use. Shall not be sent. If received, shall be interpreted as the value '2'. 


3 



8.67 Cell Identification 

The Cell Identification information element is coded as this is depicted in Figure 8.67-1. 
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Octets 

1 

2-3 

4 

5-12 

13 

14-(n-i-4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type= 131 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




Target Cell ID 


Source Type 


Source ID 



Figure 8.67-1 : Target Identification 

Source type values are specified in Table 8.67-1. 

Table 8.67-1 : Target type values and their meanings 



Location Types 


Values (Decimal) 


Cell ID 





RNCID 


1 


eNodeB ID 


2 


<spare> 


3-255 



Editor's Note: The discrepancy between this definition of Target Identification IE (which appears as though it should 
be re-titled as Cell Identification according to 3GPP TS 29.060) and the one in clause 8.59 needs to be 
resolved. 



8.68 Bearer Control Mode 



Bearer Control Mode is coded as this is depicted in Figure 8.68-1. 



Octets 

1 

2-3 

4 

5 

6-(n-h4) 


Bits 
8 7 6 5 4 3 2 1 




Type = 117 (decimal) 




Length = n (decimal) 


CR Spare Instance 


Bearer Control Mode 


These octet(s) is/are present only if explicitly specified 



Figure 8.68-1 : Bearer Flags 

Valid codes for the Bearer Control Mode octet are: 

- (Selected Bearer Control Mode - 'MS_only'); 

1 (Selected Bearer Control Mode - 'Network_only'); 

- 2 (Selected Bearer Control Mode - 'MS/NW'). 
All other values are reserved. 
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8.69 Change Reporting Action 

Change Reporting Action IE is coded as this is depicted in Figure 8.69-1. 



Octets 

1 

2-3 

4 

5-(n-H4) 


8 


Bits 
7 6 5 4 3 2 


1 




Type = 139 (decimal) 




Length = n (decimal) 


CR 


Spare Spare Instance 




Action 



Figure 8.69-1 : Change Reporting Action 
Table 8.69-1 : Action values 



Action 


Value (Decimal) 


Stop Reporting 





Start Reporting CGI/SAI 


1 


Start Reporting RAI 


2 


<spare> 


3-255 



8.70 PDN Connection Set Identifier (CSID) 

A PDN Connection Set Identifier (CSID) identifies a set of PDN connections belonging to an arbitrary number of UEs. 
The CSID is used on S5, S8 and SI 1 interfaces. 

The size of CSID is two octets. It is coded as follows: 

Editor's Note: The CSID may contain an identifier for the nodes. Such a node identifier (Node-ID) is necessary 

when MME CSID is provided to a PGW since a PGW has no reliable means of determining the identity 
of the MME that signals the partial failure messages. During other times, such a node identifier may be 
included. The exact usage and format of such a node identifier is FFS. 



Octets 

1 

2-3 

4 

5-m 

(m-Hl)-(n-H4) 


Bits 
8 7 6 5 4 3 2 


1 




Type = TBD (decimal) 




Length = n (decimal) 


CR Spare Instance 


Node-ID 


PDN Connection Set Identifier (CSID) 



Figure 8.x: CSID 



8.71 Private Extension 



Private Extension is coded as this is depicted in Figure 8. Figure 8.71-1. 

Enterprise ID can be found at lANA web site ( http ://w w w . iana. org/as signments/enterprise-numbers ) . 



Octets 

1 
2-3 

4 

5-6 
7-(n-i-4) 


8 7 


Bits 
6 5 4 3 2 


1 




Type = 255 (decimal) 




Length = n (decimal) 


CR 


Spare Instance 




Enterprise ID 


Proprietary value 



Figure 8.71-1. Private Extension 
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9 Security 

To be edited 

10 IP - The Networking Technology used by GTP 

10.1 IP Version 

GTPv2 entities shall support both versions of the Internet Protocol, version 4 as defined by IETF RFC 791 [6], and 
version 6 as defined by IETF RFC 2460 [16]. 

10.2 IP Fragmentation 

It is specified here how the fragmentation mechanism shall work with GTP-C. 

Fragmentation should be avoided if possible. Examples of fragmentation drawbacks are: 

Fragmentation is inefficient, since the complete IP header is duplicated in each fragment. 

If one fragment is lost, the complete packet has to be discarded. The reason is that no selective retransmission of 
fragments is possible. 

By using Path MTU discovery the application may find out the MTU, and thereby utilise more efficient segmentation 
mechanisms. 
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